From john.r.rose at oracle.com Thu Dec 2 16:22:59 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 03 Dec 2010 00:22:59 +0000 Subject: hg: mlvm/mlvm/jdk: indy: add reviewer Message-ID: <20101203002300.053764702F@hg.openjdk.java.net> Changeset: 8642fa612af8 Author: jrose Date: 2010-12-02 16:22 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/8642fa612af8 indy: add reviewer ! indy-bsm-7001379.patch From john.r.rose at oracle.com Fri Dec 3 15:58:10 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 03 Dec 2010 23:58:10 +0000 Subject: hg: mlvm/mlvm/hotspot: add reviewer lines, finalize indy-bsm-7001379.patch Message-ID: <20101203235810.B5BCA470A4@hg.openjdk.java.net> Changeset: d519b54740b1 Author: jrose Date: 2010-12-03 15:57 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/d519b54740b1 add reviewer lines, finalize indy-bsm-7001379.patch ! indy-bsm-7001379.patch ! indy-notrans-6981791.patch ! series From rreyelts at gmail.com Wed Dec 8 14:18:42 2010 From: rreyelts at gmail.com (Toby Reyelts) Date: Wed, 8 Dec 2010 17:18:42 -0500 Subject: Java language support for InvokeDynamic? (or using InvokeDynamic in place of codegen) Message-ID: I'm interested in understanding where Java language support is going for InvokeDynamic. The context is that I'd like to replace a system that forward-generates API with a system based on InvokeDynamic. Silly hypothetical example follows: // colors.prop color1: Red color2: Green preprocessor < colors.prop > Colors.java // generated API class Colors { Color color1() { return Color.red; } Color color2() { return Color.green; } } You get the benefits of static analysis (type-errors, code-completion, etc), but you have messy pre-processing / multi-staged compilation to deal with. One possible example of what I'd like to be able to do: Dynamic colors = ColorFactory.create("colors.prop"); Color red = colors.color1(); Color green = colors.color2(); With the right tooling support, I think I could provide the same kinds of static analysis benefits without the messiness of the preprocessor. I don't know a ton about C#, but I believe that this looks fairly achievable with the "dynamic" type. I've already read through the coin proposal and InterfaceDynamic . My understanding is that there is no language support at all for JDK 7 (correct?), but I've been playing around with the jdk7 compiler which does support the InvokeDynamic static call syntax. Unlike C#'s dynamic, it seems like there are a lot of barriers to making the above syntax work with (the proposed) Java language support. Examples I ran into with a couple of hours of playing: 1) You have to apply @BootstrapMethod to every class. 2) InvokeDynamic invocations are static. 3) InvokeDynamic calls all throw Throwable. These are all deal breakers when it comes to users using InvokeDynamic directly. Essentially, the current picture I'm seeing is that the planned language support isn't useful at all in API, as compared to implementation for alternate language runtimes. I realize that's the primary usecase, but it feels like we're missing out on a lot that invokedynamic could do for us. Are there any plans to provide anything in that direction? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101208/e637b7e9/attachment.html From forax at univ-mlv.fr Wed Dec 8 15:47:35 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 09 Dec 2010 00:47:35 +0100 Subject: Java language support for InvokeDynamic? (or using InvokeDynamic in place of codegen) In-Reply-To: References: Message-ID: <4D001917.8@univ-mlv.fr> On 12/08/2010 11:18 PM, Toby Reyelts wrote: Hi Toby, First let me say that I'm a big fan of Retroweaver. > I'm interested in understanding where Java language support is going > for InvokeDynamic. The context is that I'd like to replace a system > that forward-generates API with a system based on InvokeDynamic. Silly > hypothetical example follows: > > // colors.prop > color1: Red > color2: Green > > preprocessor < colors.prop > Colors.java > > // generated API > class Colors { > Color color1() { return Color.red; } > Color color2() { return Color.green; } > } > > You get the benefits of static analysis (type-errors, code-completion, > etc), but you have messy pre-processing / multi-staged compilation to > deal with. > > One possible example of what I'd like to be able to do: > > Dynamic colors = ColorFactory.create("colors.prop"); > Color red = colors.color1(); > Color green = colors.color2(); > > With the right tooling support, I think I could provide the same kinds > of static analysis benefits without the messiness of the preprocessor. > I don't know a ton about C#, but I believe that this looks fairly > achievable with the "dynamic" type. I don't get it. You want to do a static analysis and for that you want to use the 'dynamic' type. Hugh ? Your code above is mostly valid in C# but the dynamic invocation is done by the compiler. So if you take a to the corresponding bytecode, it's something like this: Object colors; SiteContainer0.site1.bind(null, new Object[]{"colors.prop"}, ..., &colors); // call create Object tmp1; SiteContainer0.site2.bind(colors, new Object[]{}, ..., &tmp1); // get attribute color1 Object red; SiteContainer0.site2.bind(tmp1, new Object[]{}, ..., &red); // convert to color ... As you see, the generated code is not usable to do a static analysis. > > I've already read through the coin proposal > and > InterfaceDynamic > . My understanding > is that there is no language support at all for JDK 7 (correct?), but > I've been playing around with the jdk7 compiler which does support the > InvokeDynamic static call syntax. Unlike C#'s dynamic, it seems like > there are a lot of barriers to making the above syntax work with (the > proposed) Java language support. That's correct there is no equivalent of dynamic in Java. Not because it's useless but because it's hard to do it right. > Examples I ran into with a couple of hours of playing: > > 1) You have to apply @BootstrapMethod to every class. > 2) InvokeDynamic invocations are static. > 3) InvokeDynamic calls all throw Throwable. latest spec doesn't use @BootstrapMethod anymore. 2) and 3) are still valid. > > These are all deal breakers when it comes to users using InvokeDynamic > directly. Essentially, the current picture I'm seeing is that the > planned language support isn't useful at all in API, as compared to > implementation for alternate language runtimes. I realize that's the > primary usecase, but it feels like we're missing out on a lot that > invokedynamic could do for us. Are there any plans to provide anything > in that direction? Not now. As I said, dynamic is useless for what you want to do. R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101209/bda2a4e7/attachment.html From john.r.rose at oracle.com Thu Dec 9 16:09:15 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 9 Dec 2010 16:09:15 -0800 Subject: Fwd: [jvm-l] request for advice: safepoints in the JSR 292 spec In-Reply-To: <4CB871EA.2010807@azulsystems.com> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> Message-ID: <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> I started a thread on Google Groups to get more advice on safepoint-based invalidation, which the EG is naming MutableCallSite#sync. http://groups.google.com/group/jvm-languages/browse_thread/thread/9c9d3e84fc745676# Please have a look and respond if you have any insights... -- John Begin forwarded message: From: John Rose Date: December 9, 2010 4:01:21 PM PST To: jvm-languages at googlegroups.com Subject: [jvm-l] request for advice: safepoints in the JSR 292 spec Reply-To: jvm-languages at googlegroups.com Hi everyone. On behalf of the JSR 292 EG, I'd like to ask for advice from language implementors on a deep point in our specification. For many months, the JSR 292 EG has been thinking about safepoints as an informal paradigm for thread-safe invalidation of dynamic call sites. Specifically, we need to define a mechanism to force a global update through a mutable call site, and we want a mechanism that is narrowly targeted. The narrow targeting is especially important for those of us who write JITs for machines with unusual memory architectures. ... Here's the draft language for MutableCallSite#sync: http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-1209/java/dyn/MutableCallSite.html So the question of the day is: Will this really work? In order to work, the specification has to (a) make logical sense in the terms of the JMM, (b) be reasonably implementable by JVMs, and (c) be useful to programmers. Indeed, that's a tall order, but I think the above language meets all three requirements. The JSR 292 EG would deeply appreciate anyone pointing out flaws in this reasoning. Best wishes, -- John P.S. If this pattern works, we are likely to apply variations of in two other places in the 292 spec, ClassValue and Switcher. See the draft javadoc for details. Cliff Click has pointed out that a generalized optimization on volatile variables would have about the same effect. Perhaps this is what JVMs will be doing routinely in five years, but the 292 API needs this pattern in only a few set places, and so the EG is content to roll it out in a limited way right now. P.P.S. This is probably the biggest issue which is preventing us from finalizing JSR 292. Please see the items marked "PROVISIONAL" in the draft javadoc if you are curious about what's left to clean up. The bleeding edge draft of 292 is always at http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101209/62cada43/attachment.html From dl at cs.oswego.edu Fri Dec 10 05:08:28 2010 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 10 Dec 2010 08:08:28 -0500 Subject: request for advice: safepoints in the JSR 292 spec In-Reply-To: <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> Message-ID: <4D02264C.206@cs.oswego.edu> On 12/09/10 19:09, John Rose wrote: > I started a thread on Google Groups to get more advice on safepoint-based > invalidation, which the EG is naming MutableCallSite#sync. > > http://groups.google.com/group/jvm-languages/browse_thread/thread/9c9d3e84fc745676# > TL;DR version: The scheme you laid out here seems sound. (To avoid relays/forks of discussions, I tried joining and CCing the group) My only concern about this is whether it precludes further useful support for the general problem of "phased computation", which is in turn either a variant of or a generalization of fork/join computation, depending on how you look at it. Since JDK7 includes integrated support for both ForkJoinTask and Phaser, that will both probably be used in JDK8 lambdas etc, it seems almost a sure thing that people will further explore underlying JVM support. Here's a synopsis of issues. (Please bear with the background before returning to questions at hand.) Phased and fork/join computations impose enough structure on parallel computations to allow cheaper low-level memory-level accesses. Well, at least when they are used in the intended ways; among the main difference between JDK7 support and explicitly parallel languages like X10 (supporting "clocks" (a form of Phasers) and async/finish (a form of fork/join)) is that Java compilers cannot enforce correct usage (although tools and IDE plugins could be improved/developed that could do so in most cases). As warmup, for fork/join, the main economies are due to the static DAG structure of computation. Among other impacts, accessing a variable modified by a joined task requires no memory-level sync beyond what was required anyway to determine the join. (We currently have no way to designate such variables or usages; better support probably awaits this.) For phased computations, the main economies apply to "phased" variables -- those that may take a new value on each phase but are constant within phases. (We also don't have a way of designating these.) Conceptually, a phased variable is a holder of two values/variables, call them "current" and "next", where reads are from "current" and writes are to "next". In existing JMM-ese, "current" is basically a non-volatile variable, and "next" is volatile. And conceptually, upon each phase advance, each party does "current = next". There are a few ways to implement this differently though. One common option is to use only a single location per phased variable, and to arrange an action taken upon phase advance to do in-place updates (see for example Phaser.onAdvance, http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/Phaser.html which must by nature be performed in exclusion since all other parties are blocked until advance. Another option is to use a two-slot array per phased variable, indexed by the lowest bit of phase number: reads are from slot[phase & 1], writes are to slot[~phase & 1] (assuming that phase numbers are explicit and sequential). This avoids the need for copying. Also, across all of these, it is possible and sometimes desirable for parties to use their own writes early, before advance. Sadly enough, I don't know of a recipe determining which of these options is best in a given situation. (Although I do know one of the ingredients: whether you require atomicity of updates across all parties upon advance.) Maybe some further study and exploration could arrive at a good recipe. In the mean time, note that only one of these options (explicit current+next) even has a reasonable interpretation in existing JVM-ese. The others are mismatched in that some of the operations have JMM-volatile semantics and some don't, so it doesn't make sense to declare the variable as either volatile or non-volatile. John's proposal for MutableCallSite falls into this category, hence the controversy about how to express it. It is a specialization of the onAdvance (aka sync()) approach with in-place updates, and safepoint generations serving as phases. This seems reasonable given the likely need for atomicity during safepoints anyway. While ideally it would be nice to integrate this with other phased computation even now (I can imagine defining adjunct classes for use with j.u.c.Phaser), I'm not too tempted to do so right now, because it is not always the best available option. However, someday, it would be great to be able to allow use the same mechanics in each. As parallelism becomes more widespread, we must make it easiest and most attractive for people to use simpler constrained execution control patterns like phasers and FJ rather than the ad-hoc unstructured use of threads/volatiles/locks. One way to help reach this goal is to improve JVM-level support so that the most structured parallel code is also the fastest parallel code. -Doug From brian.goetz at oracle.com Fri Dec 10 10:33:35 2010 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 10 Dec 2010 13:33:35 -0500 Subject: request for advice: safepoints in the JSR 292 spec In-Reply-To: <4D02264C.206@cs.oswego.edu> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> Message-ID: <4D02727F.9020905@oracle.com> > However, someday, it would be great to be able > to allow use the same mechanics in each. As parallelism > becomes more widespread, we must make it easiest and > most attractive for people to use simpler constrained > execution control patterns like phasers and FJ rather than the > ad-hoc unstructured use of threads/volatiles/locks. And, while we're at it, let's not forget the serviceability side to this. If some doofus incorrectly tags a hot field as being an epochal variable, performance is going to suck for reasons that traditional profilers will not be able to measure. Which means we also want to consider VM mechanisms for tracking the effectiveness of such mechanisms at the same time we design the mechanism. From john.r.rose at oracle.com Fri Dec 10 18:04:11 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 10 Dec 2010 18:04:11 -0800 Subject: request for advice: safepoints in the JSR 292 spec In-Reply-To: <4D02264C.206@cs.oswego.edu> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> Message-ID: On Dec 10, 2010, at 5:08 AM, Doug Lea wrote: > On 12/09/10 19:09, John Rose wrote: >> I started a thread on Google Groups to get more advice on safepoint-based >> invalidation, which the EG is naming MutableCallSite#sync. >> >> http://groups.google.com/group/jvm-languages/browse_thread/thread/9c9d3e84fc745676# >> > > TL;DR version: The scheme you laid out here seems sound. Thanks very much, Doug. I assume you are primarily referring to part (a) of my question: >> In order to work, the specification has to (a) make logical sense in the terms of the JMM, (b) be reasonably implementable by JVMs, and (c) be useful to programmers. Does anyone have a take on (c)? (See my comments below on using this API...) > My only concern about this is whether it precludes > further useful support for the general problem > of "phased computation"... I hope not, though JSRs 292 and 166 are an instance of: http://en.wikipedia.org/wiki/Conway's_Law The worst case is that we are seeing the good being the enemy of the better. The best case is we are doing initial exercises in JDK 7 which will get well-structured in JDK 8. I vote for best case. The device of associating a "nonce-volatile" with a safepoint-phased variable update is generally applicable, not just to MutableCallSite. Perhaps once we have a suitable LValue abstraction (able to efficiently refer to x.f or a[i], which are your two implementations of phased variables), we can make a standard operation LValue.setOnceVolatile. Doug, you've asked before for LValue. As we've discussed, in order to do LValue, the JVM needs very reliable scalarization. This means alleviating certain obstacles from the JOM (Java Object Model), notably pointer comparison and monitor-per-object. Tuples would help also. The MLVM project needs to work on this stuff; the key resource shortage is the most valuable resource, which is people (esp. HotSpot hackers) to think and work on it. > For phased computations, the main economies apply > to "phased" variables -- those that may take a > new value on each phase but are constant within phases. Thanks for this concept. > Sadly enough, I don't know of a recipe determining which > of these options is best in a given situation. (Although > I do know one of the ingredients: whether you require > atomicity of updates across all parties upon advance.) > Maybe some further study and exploration could arrive at a > good recipe. In the JSR 292 case, we are supporting languages (like Java!) which can dynamically change their type schemas, but do so infrequently, perhaps at phase changes. The changes will in general require complex sets of call sites to be updated, implying a dependency mechanism (see the Switcher class for this). But the actual change-over can be slow, and may involve safepoints, as today with devirtualization that happens when new classes are loaded. (See Universe::flush_dependents_on around line 1100 of: http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/tip/src/share/vm/memory/universe.cpp ) The idea is that the type schema change would be prepared (as a "next global state") by a writer thread #1. At this point some call sites become "invalid in next state". Those call sites would be switched, either by a switcher (which would in general control many call sites at once) or by editing them individually, and then calling 'sync' on them. The new state of all call sites must at this point be consistent with both the current and next global state of the type schema. Typically, a lock would be held on the schema by writer thread #1, and the updated call site paths (now switched in and sync-ed) would pile up on the schema lock. After the next global state is installed as current, the writer thread #1 lets go of the lock, and callers are free to shake out the new state of affairs. The shake-out may include installing optimized call paths in various call sites. This means that a mutable call site might undergo two mutations, the first to get into a state consistent with both old and new schemas (perhaps seizing a lock, as above) and the second to optimize calling within the new state. Both transitions generally need to grab a lock so they can have a consistent view of the global schema state. As an extra complication, the editing of call sites is probably performed in a concurrent manner, and lazily. There might be writer thread #2, etc., performing updates to mutable call sites. It it not clear to me whether the second write also needs a sync, but it looks like that may be the case to get performance. Perhaps the right way to go is avoid the second write, and have the first write install the optimized path immediately, and queuing a 'sync' request to be executed after a short delay. One key concern is to avoid "safepoint storms", by batching 'sync' requests. > In the mean time, note that only one of these options > (explicit current+next) even has a reasonable interpretation > in existing JVM-ese. The others are mismatched in that > some of the operations have JMM-volatile semantics and some > don't, so it doesn't make sense to declare the variable > as either volatile or non-volatile. > > John's proposal for MutableCallSite falls into this category, > hence the controversy about how to express it. > It is a specialization of the onAdvance (aka sync()) approach > with in-place updates, and safepoint generations serving > as phases. This seems reasonable given the likely need for > atomicity during safepoints anyway. I'd like to build both on top of LValue operations, but not in JDK 7. Someone with a thesis to write should propose some conservative additions to the JMM to operate on LValues (or something like them). They can start with nonce-volatiles, but there are probably better ideas waiting to be recognized. > While ideally it would be nice to integrate this with > other phased computation even now (I can imagine defining > adjunct classes for use with j.u.c.Phaser), I'm not too > tempted to do so right now, because it is not always the > best available option. Let's keep thinking about building blocks, for inclusion in a JDK 7+O(1). > One > way to help reach this goal is to improve JVM-level support > so that the most structured parallel code is also the fastest > parallel code. Yes. If the fastest code is unstructured, the fastest code will be unreasonably expensive in most cases. Which would be dumb economics. -- John From richhickey at gmail.com Sat Dec 11 06:52:03 2010 From: richhickey at gmail.com (Rich Hickey) Date: Sat, 11 Dec 2010 09:52:03 -0500 Subject: request for advice: safepoints in the JSR 292 spec In-Reply-To: References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> Message-ID: <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> On Dec 10, 2010, at 9:04 PM, John Rose wrote: > On Dec 10, 2010, at 5:08 AM, Doug Lea wrote: > >> On 12/09/10 19:09, John Rose wrote: >>> I started a thread on Google Groups to get more advice on >>> safepoint-based >>> invalidation, which the EG is naming MutableCallSite#sync. >>> >>> http://groups.google.com/group/jvm-languages/browse_thread/thread/9c9d3e84fc745676# >>> >> >> TL;DR version: The scheme you laid out here seems sound. > > Thanks very much, Doug. I assume you are primarily referring to > part (a) of my question: > >>> In order to work, the specification has to (a) make logical sense >>> in the terms of the JMM, (b) be reasonably implementable by JVMs, >>> and (c) be useful to programmers. > > Does anyone have a take on (c)? (See my comments below on using > this API...) > > In the JSR 292 case, we are supporting languages (like Java!) which > can dynamically change their type schemas, but do so infrequently, > perhaps at phase changes. The changes will in general require > complex sets of call sites to be updated, implying a dependency > mechanism (see the Switcher class for this). But the actual change- > over can be slow, and may involve safepoints, as today with > devirtualization that happens when new classes are loaded. > > (See Universe::flush_dependents_on around line 1100 of: > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/tip/src/share/vm/memory/universe.cpp > ) > > The idea is that the type schema change would be prepared (as a > "next global state") by a writer thread #1. At this point some call > sites become "invalid in next state". Those call sites would be > switched, either by a switcher (which would in general control many > call sites at once) or by editing them individually, and then > calling 'sync' on them. > > The new state of all call sites must at this point be consistent > with both the current and next global state of the type schema. > Typically, a lock would be held on the schema by writer thread #1, > and the updated call site paths (now switched in and sync-ed) would > pile up on the schema lock. After the next global state is > installed as current, the writer thread #1 lets go of the lock, and > callers are free to shake out the new state of affairs. > > The shake-out may include installing optimized call paths in various > call sites. This means that a mutable call site might undergo two > mutations, the first to get into a state consistent with both old > and new schemas (perhaps seizing a lock, as above) and the second to > optimize calling within the new state. Both transitions generally > need to grab a lock so they can have a consistent view of the global > schema state. > > As an extra complication, the editing of call sites is probably > performed in a concurrent manner, and lazily. There might be writer > thread #2, etc., performing updates to mutable call sites. It it > not clear to me whether the second write also needs a sync, but it > looks like that may be the case to get performance. Perhaps the > right way to go is avoid the second write, and have the first write > install the optimized path immediately, and queuing a 'sync' request > to be executed after a short delay. One key concern is to avoid > "safepoint storms", by batching 'sync' requests. > > -- John Thanks for this work, John! I'm concerned about the separation of update and publication in this API. It seems intractably difficult to reason about the behavior of the system between multiple setTarget() calls and a subsequent sync(). I'd much rather see (if possible): public static void syncTargets(MutableCallSite[] sites, MethodHandle[] newTargets) Then we can create arbitrary composite updates, out of view and over time, using mere-mortals programming, and deliver them atomically. Ditto Switchers (if they would even still be needed). And I wonder about VolatileCallSite. Who would ever use that, given MutableCallSite? Perhaps setTarget() should simply go away? Regards, Rich From jlaskey at me.com Sat Dec 11 08:31:46 2010 From: jlaskey at me.com (Jim Laskey) Date: Sat, 11 Dec 2010 12:31:46 -0400 Subject: request for advice: safepoints in the JSR 292 spec In-Reply-To: <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> Message-ID: <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> > public static void syncTargets(MutableCallSite[] sites, MethodHandle[] newTargets) +1 I think this provides the most flexibility, performance and ease. If a developer wants to use a wrapper method to do one up 'set and sync', they have the flexibility to do so. Naive question: If setTarget is removed and set is done either by constructor or by syncTargets, do we still need both these flavours of CallSite? Cheers, -- Jim On 2010-12-11, at 10:52 AM, Rich Hickey wrote: > > On Dec 10, 2010, at 9:04 PM, John Rose wrote: > >> On Dec 10, 2010, at 5:08 AM, Doug Lea wrote: >> >>> On 12/09/10 19:09, John Rose wrote: >>>> I started a thread on Google Groups to get more advice on >>>> safepoint-based >>>> invalidation, which the EG is naming MutableCallSite#sync. >>>> >>>> http://groups.google.com/group/jvm-languages/browse_thread/thread/9c9d3e84fc745676# >>>> >>> >>> TL;DR version: The scheme you laid out here seems sound. >> >> Thanks very much, Doug. I assume you are primarily referring to >> part (a) of my question: >> >>>> In order to work, the specification has to (a) make logical sense >>>> in the terms of the JMM, (b) be reasonably implementable by JVMs, >>>> and (c) be useful to programmers. >> >> Does anyone have a take on (c)? (See my comments below on using >> this API...) >> >> In the JSR 292 case, we are supporting languages (like Java!) which >> can dynamically change their type schemas, but do so infrequently, >> perhaps at phase changes. The changes will in general require >> complex sets of call sites to be updated, implying a dependency >> mechanism (see the Switcher class for this). But the actual change- >> over can be slow, and may involve safepoints, as today with >> devirtualization that happens when new classes are loaded. >> >> (See Universe::flush_dependents_on around line 1100 of: >> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/tip/src/share/vm/memory/universe.cpp >> ) >> >> The idea is that the type schema change would be prepared (as a >> "next global state") by a writer thread #1. At this point some call >> sites become "invalid in next state". Those call sites would be >> switched, either by a switcher (which would in general control many >> call sites at once) or by editing them individually, and then >> calling 'sync' on them. >> >> The new state of all call sites must at this point be consistent >> with both the current and next global state of the type schema. >> Typically, a lock would be held on the schema by writer thread #1, >> and the updated call site paths (now switched in and sync-ed) would >> pile up on the schema lock. After the next global state is >> installed as current, the writer thread #1 lets go of the lock, and >> callers are free to shake out the new state of affairs. >> >> The shake-out may include installing optimized call paths in various >> call sites. This means that a mutable call site might undergo two >> mutations, the first to get into a state consistent with both old >> and new schemas (perhaps seizing a lock, as above) and the second to >> optimize calling within the new state. Both transitions generally >> need to grab a lock so they can have a consistent view of the global >> schema state. >> >> As an extra complication, the editing of call sites is probably >> performed in a concurrent manner, and lazily. There might be writer >> thread #2, etc., performing updates to mutable call sites. It it >> not clear to me whether the second write also needs a sync, but it >> looks like that may be the case to get performance. Perhaps the >> right way to go is avoid the second write, and have the first write >> install the optimized path immediately, and queuing a 'sync' request >> to be executed after a short delay. One key concern is to avoid >> "safepoint storms", by batching 'sync' requests. >> >> -- John > > Thanks for this work, John! > I'm concerned about the separation of update and publication in this > API. It seems intractably difficult to reason about the behavior of > the system between multiple setTarget() calls and a subsequent sync(). > > I'd much rather see (if possible): > > public static void syncTargets(MutableCallSite[] sites, MethodHandle[] > newTargets) > > Then we can create arbitrary composite updates, out of view and over > time, using mere-mortals programming, and deliver them atomically. > > Ditto Switchers (if they would even still be needed). And I wonder > about VolatileCallSite. Who would ever use that, given MutableCallSite? > > Perhaps setTarget() should simply go away? > > Regards, > > Rich > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From forax at univ-mlv.fr Sat Dec 11 12:38:19 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 11 Dec 2010 21:38:19 +0100 Subject: request for advice: safepoints in the JSR 292 spec In-Reply-To: <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> Message-ID: <4D03E13B.6000402@univ-mlv.fr> On 12/11/2010 05:31 PM, Jim Laskey wrote: >> public static void syncTargets(MutableCallSite[] sites, MethodHandle[] newTargets) > +1 > > I think this provides the most flexibility, performance and ease. If a developer wants to use a wrapper method to do one up 'set and sync', they have the flexibility to do so. > > Naive question: If setTarget is removed and set is done either by constructor or by syncTargets, do we still need both these flavours of CallSite? > > Cheers, > > -- Jim I think it's possible to use a synchronized block enclosing the setTargets and the corresponding syncs instead of syncTargets. From my experience, changing something on a metaclass often require to propagate changes on subclasses. This can't be done using atomics so you already need such synchronized block. The CallSite's constructor that takes a target is not that useful because usually you bind the CallSite object to the method handle chain. Otherwise, you have no CallSite to call sync on it. Moreover, depending on the runtime language you know some invariants, by example, some languages doesn't allow to change the operator +, in that case calling sync to update a callsite that uses + is an unnecessary cost. R?mi From jlaskey at me.com Sat Dec 11 15:30:22 2010 From: jlaskey at me.com (Jim Laskey) Date: Sat, 11 Dec 2010 19:30:22 -0400 Subject: request for advice: safepoints in the JSR 292 spec In-Reply-To: <4D03E13B.6000402@univ-mlv.fr> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> <4D03E13B.6000402@univ-mlv.fr> Message-ID: On 2010-12-11, at 4:38 PM, R?mi Forax wrote: > I think it's possible to use a synchronized block enclosing the setTargets and the corresponding syncs > instead of syncTargets. From my experience, changing something on a metaclass > often require to propagate changes on subclasses. This can't be done using atomics > so you already need such synchronized block. Maybe I misunderstood. I was assuming that syncTargets was a VM operation (at safepoint.) From richhickey at gmail.com Sun Dec 12 08:02:17 2010 From: richhickey at gmail.com (Rich Hickey) Date: Sun, 12 Dec 2010 11:02:17 -0500 Subject: request for advice: safepoints in the JSR 292 spec In-Reply-To: References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> <4D03E13B.6000402@univ-mlv.fr> Message-ID: <24AB6D82-EDD5-431F-81D4-6E9C4202BC36@gmail.com> On Dec 11, 2010, at 6:30 PM, Jim Laskey wrote: > > On 2010-12-11, at 4:38 PM, R?mi Forax wrote: > >> I think it's possible to use a synchronized block enclosing the >> setTargets and the corresponding syncs >> instead of syncTargets. From my experience, changing something on a >> metaclass >> often require to propagate changes on subclasses. This can't be >> done using atomics >> so you already need such synchronized block. > > Maybe I misunderstood. I was assuming that syncTargets was a VM > operation (at safepoint.) > > Right. R?mi's synchronized block only coordinates the activities of updaters. Other threads may, and in some cases may have to, see some of the setTarget results prior to the sync call, which could be a mess. The point of syncTargets is to make the setting and the visibility atomic, which synchronized cannot do. Rich From forax at univ-mlv.fr Mon Dec 13 00:19:07 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 13 Dec 2010 09:19:07 +0100 Subject: request for advice: safepoints in the JSR 292 spec In-Reply-To: <24AB6D82-EDD5-431F-81D4-6E9C4202BC36@gmail.com> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> <4D03E13B.6000402@univ-mlv.fr> <24AB6D82-EDD5-431F-81D4-6E9C4202BC36@gmail.com> Message-ID: <4D05D6FB.4020808@univ-mlv.fr> On 12/12/2010 05:02 PM, Rich Hickey wrote: > > On Dec 11, 2010, at 6:30 PM, Jim Laskey wrote: > >> >> On 2010-12-11, at 4:38 PM, R?mi Forax wrote: >> >>> I think it's possible to use a synchronized block enclosing the >>> setTargets and the corresponding syncs >>> instead of syncTargets. From my experience, changing something on a >>> metaclass >>> often require to propagate changes on subclasses. This can't be done >>> using atomics >>> so you already need such synchronized block. >> >> Maybe I misunderstood. I was assuming that syncTargets was a VM >> operation (at safepoint.) >> >> > > Right. > > R?mi's synchronized block only coordinates the activities of updaters. > Other threads may, and in some cases may have to, see some of the > setTarget results prior to the sync call, which could be a mess. The > point of syncTargets is to make the setting and the visibility atomic, > which synchronized cannot do. > > Rich > Rich, I don't think you can provide an optimized method handle when syncing but more probably a default generic method that will later installs a fast path. So if the result of setTarget is visible before the sync call, it will execute a default generic method which will also enter in a synchronized block. This will effectively coordinate things between readers and writers. invariant broken (writer): synchronized(masterLock) { // mutate meta data // update all callsites foreach(impacted callsites) { callsite.setTarget(callsite.defaultGenericPath); } sync(impacted callsites); } default generic method (reader): synchonized(masterLock) { // check arguments // use meta data to create a fast path } setTarget(guard + fastpath); This pattern intends to mimick the way the VM do lazy deoptimization i.e mark the callsite as deoptimized and later when the callsite is used re-create a fast path. R?mi From forax at univ-mlv.fr Tue Dec 14 09:02:22 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 14 Dec 2010 18:02:22 +0100 Subject: Spurious NPE in guardWithTest Message-ID: <4D07A31E.2070309@univ-mlv.fr> With the jdk7b121, sometimes when I call a MH created with guardWith, it get a NPE because the target is NULL :( groovy examples/mixin.groovy java.lang.NullPointerException at sun.dyn.MethodHandleImpl$GuardWithTest.invoke_L1(MethodHandleImpl.java:963) at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:336) at org.codehaus.groovy2.lang.MOPLinker.fallback(MOPLinker.java:145) at sun.dyn.FilterGeneric$F1.invoke_C0(FilterGeneric.java:516) at mixin.run(Unknown Source) at groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:264) at groovy.lang.GroovyShell.run(GroovyShell.java:227) at groovy.lang.GroovyShell.run(GroovyShell.java:157) at groovy.ui.GroovyMain.processOnce(GroovyMain.java:496) at groovy.ui.GroovyMain.run(GroovyMain.java:311) at groovy.ui.GroovyMain.process(GroovyMain.java:297) at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112) at groovy.ui.GroovyMain.main(GroovyMain.java:93) Caught: java.lang.NullPointerException Because MHs.guardWithTest() explicitly test that the target is not null, I think there is a bug somewhere in the VM. Step to reproduce: download Gru: http://www-igm.univ-mlv.fr/~forax/tmp/Gru.tgz run: groovy examples/mixin.groovy It should print some bytecodes and "groovy yai" ... if there is no NPE. R?mi PS: yes, Gru a prototype of groovy on top of JSR292 :) From christian.thalinger at oracle.com Tue Dec 14 09:10:33 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 14 Dec 2010 18:10:33 +0100 Subject: Spurious NPE in guardWithTest In-Reply-To: <4D07A31E.2070309@univ-mlv.fr> References: <4D07A31E.2070309@univ-mlv.fr> Message-ID: On Dec 14, 2010, at 6:02 PM, R?mi Forax wrote: > With the jdk7b121, sometimes when I call a MH created with guardWith, it > get a NPE because the target is NULL :( > > groovy examples/mixin.groovy > > java.lang.NullPointerException > at > sun.dyn.MethodHandleImpl$GuardWithTest.invoke_L1(MethodHandleImpl.java:963) > at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:336) > at org.codehaus.groovy2.lang.MOPLinker.fallback(MOPLinker.java:145) > at sun.dyn.FilterGeneric$F1.invoke_C0(FilterGeneric.java:516) > at mixin.run(Unknown Source) > at > groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:264) > at groovy.lang.GroovyShell.run(GroovyShell.java:227) > at groovy.lang.GroovyShell.run(GroovyShell.java:157) > at groovy.ui.GroovyMain.processOnce(GroovyMain.java:496) > at groovy.ui.GroovyMain.run(GroovyMain.java:311) > at groovy.ui.GroovyMain.process(GroovyMain.java:297) > at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112) > at groovy.ui.GroovyMain.main(GroovyMain.java:93) > Caught: java.lang.NullPointerException > > Because MHs.guardWithTest() explicitly test that the target is not null, > I think there is a bug somewhere in the VM. Does it also happen with -Xint? Or C1? I guess you're using C2. > > Step to reproduce: > download Gru: http://www-igm.univ-mlv.fr/~forax/tmp/Gru.tgz > > run: groovy examples/mixin.groovy > > It should print some bytecodes and "groovy yai" ... > if there is no NPE. I will have a look. > > R?mi > PS: yes, Gru a prototype of groovy on top of JSR292 :) Nice! -- Christian From forax at univ-mlv.fr Tue Dec 14 11:12:29 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 14 Dec 2010 20:12:29 +0100 Subject: Spurious NPE in guardWithTest In-Reply-To: References: <4D07A31E.2070309@univ-mlv.fr> Message-ID: <4D07C19D.2040907@univ-mlv.fr> On 12/14/2010 06:10 PM, Christian Thalinger wrote: > On Dec 14, 2010, at 6:02 PM, R?mi Forax wrote: >> With the jdk7b121, sometimes when I call a MH created with guardWith, it >> get a NPE because the target is NULL :( >> >> groovy examples/mixin.groovy >> >> java.lang.NullPointerException >> at >> sun.dyn.MethodHandleImpl$GuardWithTest.invoke_L1(MethodHandleImpl.java:963) >> at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:336) >> at org.codehaus.groovy2.lang.MOPLinker.fallback(MOPLinker.java:145) >> at sun.dyn.FilterGeneric$F1.invoke_C0(FilterGeneric.java:516) >> at mixin.run(Unknown Source) >> at >> groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:264) >> at groovy.lang.GroovyShell.run(GroovyShell.java:227) >> at groovy.lang.GroovyShell.run(GroovyShell.java:157) >> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:496) >> at groovy.ui.GroovyMain.run(GroovyMain.java:311) >> at groovy.ui.GroovyMain.process(GroovyMain.java:297) >> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112) >> at groovy.ui.GroovyMain.main(GroovyMain.java:93) >> Caught: java.lang.NullPointerException >> >> Because MHs.guardWithTest() explicitly test that the target is not null, >> I think there is a bug somewhere in the VM. > Does it also happen with -Xint? Or C1? I guess you're using C2. Xint => same problem I use C2 on a 64bits VM, I could reproduce it with C2 using a 32bits VM but not with C1 (32bits VM). >> Step to reproduce: >> download Gru: http://www-igm.univ-mlv.fr/~forax/tmp/Gru.tgz >> >> run: groovy examples/mixin.groovy >> >> It should print some bytecodes and "groovy yai" ... >> if there is no NPE. > I will have a look. > >> R?mi >> PS: yes, Gru a prototype of groovy on top of JSR292 :) > Nice! > > -- Christian R?mi From john.r.rose at oracle.com Tue Dec 14 22:31:59 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 14 Dec 2010 22:31:59 -0800 Subject: request for advice: safepoints in the JSR 292 spec In-Reply-To: <4D05D6FB.4020808@univ-mlv.fr> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> <4D03E13B.6000402@univ-mlv.fr> <24AB6D82-EDD5-431F-81D4-6E9C4202BC36@gmail.com> <4D05! D6FB.4020808@univ-mlv.fr> Message-ID: <216E098D-8930-4476-B93D-038DC422AE6F@oracle.com> On Dec 13, 2010, at 12:19 AM, R?mi Forax wrote: > On 12/12/2010 05:02 PM, Rich Hickey wrote: >> R?mi's synchronized block only coordinates the activities of updaters. >> Other threads may, and in some cases may have to, see some of the >> setTarget results prior to the sync call, which could be a mess. The >> point of syncTargets is to make the setting and the visibility atomic, >> which synchronized cannot do. Yes, syncTargets would be very powerful. But it would also be hard to require of all JVMs. Speaking only for HotSpot, we don't do everything with safepoints, because they are expensive. We use racy updates whenever we can get away with it. The cost of a racy update is the co-existence of two states, unpredictably visible to various threads. I think that's a normal complexity cost for doing good language implementations. I think mapping a global atomic update to the JMM would require more "magic edges" in the happens-before graph. The proposal I posted, while weaker, has a correspondingly simpler impact on the JMM. This is another way of observing that JVMs are likely to have an easier time of adding the proposed functionality. So a globally atomic update is harder to implement and harder to specify. It is also overkill for a common use case, which is delayed optimization of call sites. See below... > Rich, > I don't think you can provide an optimized method handle when syncing but > more probably a default generic method that will later installs a fast path. Thanks, Remi, for explaining this. I'm going to pile on here. (I have one comment on your code; see below.) I think of the pattern Remi sketches as a 2-phase commit. Phase 0 and phase 2 are long-term phases. Phase 1 is brief but not atomic. Phase 0 is the reign of the old target T0, before any MCS.setTarget. Phase 1 starts when metadata locks are grabbed. Under the locks, MCS.setTarget installs a default generic method T1. (This is analogous to the JVM trick of setting a call site to the "unlinked" state.) T1 is not racy. It is careful to grab a reader lock on metadata. It is likely to install an optimized method T2, via a simple setTarget. This may happen after an invocation count, or after user-level profiling. (Therefore, it does not make sense to try to guess at T2 during phase 1.) The MCS.sync operation is performed during phase 1, after all relevant setTargets are done. It has the effect of excluding threads from observing target T0. (I.e., it "flushes" T0 from the system.) Phase 2 starts when metadata locks are released. During phase 2, individual threads eventually execute T1. T1 lazily decides to install T2. (Or several equivalent versions of T2.) Threads which observe T1 (because of caching or inlining) will perform sync actions which will force them to observe more recent call site targets. During phase 0, T2 cannot be observed. During phase2, T0 cannot be observed. The intermediate target T1 can be observed during any phase. Compare that with Rich's proposed atomic syncTargets operation, which would exclude phase 1 and target T1, for better and worse. Another way of comparing syncTargets with setTarget+sync is simply to syncTargets excludes target T1 from phase 0, whereas the weaker proposal does not exclude T1. This weakness can also be described in terms of two reader threads, a Fast Reader and a Slow Reader. The Fast Reader sees the result of the writer's setTarget of T1 in the same nanosecond. The Slow Reader sees only T0 until it is forced to pick up T1 by the sync operation. -- John > So if the result of setTarget is visible before the sync call, it will > execute > a default generic method which will also enter in a synchronized block. > This will effectively coordinate things between readers and writers. > > invariant broken (writer): > synchronized(masterLock) { > // mutate meta data > // update all callsites > foreach(impacted callsites) { > callsite.setTarget(callsite.defaultGenericPath); > } > sync(impacted callsites); > } > > default generic method (reader): > synchonized(masterLock) { > // check arguments > // use meta data to create a fast path > } (This next line should also be synchronized. -- JRR) > setTarget(guard + fastpath); > > > This pattern intends to mimick the way the VM do lazy deoptimization > i.e mark the callsite as deoptimized and later when the callsite is used > re-create a fast path. From richhickey at gmail.com Wed Dec 15 09:22:05 2010 From: richhickey at gmail.com (Rich Hickey) Date: Wed, 15 Dec 2010 12:22:05 -0500 Subject: request for advice: safepoints in the JSR 292 spec In-Reply-To: <216E098D-8930-4476-B93D-038DC422AE6F@oracle.com> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <45C8E498-9060-4DA8-8FA0-22012D99EE36@oracle.com> <4CA73D67.6060201@cs.oswego.edu> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> <4D03E13B.6000402@univ-mlv.fr> <24AB6D82-EDD5-431F-81D4-6E9C4202BC36@gmail.com> <4D05! D6FB.4020808@univ-mlv.fr> <216E098D-8930-4476-B93D-038DC422AE6F@oracle.com> Message-ID: <9EE2AA1D-63FD-400D-89DF-ADA4569F0E93@gmail.com> On Dec 15, 2010, at 1:31 AM, John Rose wrote: > On Dec 13, 2010, at 12:19 AM, R?mi Forax wrote: >> On 12/12/2010 05:02 PM, Rich Hickey wrote: >>> R?mi's synchronized block only coordinates the activities of >>> updaters. >>> Other threads may, and in some cases may have to, see some of the >>> setTarget results prior to the sync call, which could be a mess. The >>> point of syncTargets is to make the setting and the visibility >>> atomic, >>> which synchronized cannot do. > > Yes, syncTargets would be very powerful. But it would also be hard to > require of all JVMs. Speaking only for HotSpot, we don't do > everything > with safepoints, because they are expensive. We use racy updates > whenever we can get away with it. The cost of a racy update is the > co-existence of two states, unpredictably visible to various threads. > I think that's a normal complexity cost for doing good language > implementations. > > I think mapping a global atomic update to the JMM would require > more "magic edges" in the happens-before graph. The proposal > I posted, while weaker, has a correspondingly simpler impact on > the JMM. This is another way of observing that JVMs are likely to > have an easier time of adding the proposed functionality. > > So a globally atomic update is harder to implement and harder > to specify. It is also overkill for a common use case, which is > delayed optimization of call sites. See below... > >> Rich, >> I don't think you can provide an optimized method handle when >> syncing but >> more probably a default generic method that will later installs a >> fast path. > > Thanks, Remi, for explaining this. I'm going to pile on here. > > (I have one comment on your code; see below.) > > I think of the pattern Remi sketches as a 2-phase commit. > > Phase 0 and phase 2 are long-term phases. Phase 1 is brief but not > atomic. > > Phase 0 is the reign of the old target T0, before any MCS.setTarget. > > Phase 1 starts when metadata locks are grabbed. > Under the locks, MCS.setTarget installs a default generic method T1. > (This is analogous to the JVM trick of setting a call site to the > "unlinked" state.) > > T1 is not racy. It is careful to grab a reader lock on metadata. > It is likely to install an optimized method T2, via a simple > setTarget. > This may happen after an invocation count, or after user-level > profiling. > (Therefore, it does not make sense to try to guess at T2 during > phase 1.) > > The MCS.sync operation is performed during phase 1, after all > relevant setTargets are done. It has the effect of excluding threads > from observing target T0. (I.e., it "flushes" T0 from the system.) > > Phase 2 starts when metadata locks are released. During phase 2, > individual threads eventually execute T1. T1 lazily decides to > install T2. > (Or several equivalent versions of T2.) > > Threads which observe T1 (because of caching or inlining) will perform > sync actions which will force them to observe more recent call site > targets. > > During phase 0, T2 cannot be observed. During phase2, T0 cannot be > observed. > The intermediate target T1 can be observed during any phase. > > Compare that with Rich's proposed atomic syncTargets operation, > which would exclude phase 1 and target T1, for better and worse. > > Another way of comparing syncTargets with setTarget+sync is > simply to syncTargets excludes target T1 from phase 0, whereas > the weaker proposal does not exclude T1. > > This weakness can also be described in terms of two reader > threads, a Fast Reader and a Slow Reader. The Fast Reader > sees the result of the writer's setTarget of T1 in the same > nanosecond. The Slow Reader sees only T0 until it is > forced to pick up T1 by the sync operation. > > This API has several presumptions: - There is some singular global metadata. - It is protected by a lock. What if it is an immutable structure in an AtomicReference and modified via CAS? Or passed by value to targets/ handles? - Call sites will always use a two-phase update, i.e. they will need to rediscover their binding vs directly target it (during metadata update) given their cached data and the new metadata. You are piggybacking on this presumption to provide a consistency hook (blocking on the read lock). While T1 is not strictly MT racy (given the adoption of this pattern wholesale), it is prone to error, in that should the update phase interleave ordinary code and setTarget calls, it can see an inconsistent state (i.e. nothing keeps call sites the update thread encounters from moving to T1.5 prior to the sync call, since the updater thread holds the lock). Many dynamic language implementations use their own dynamic code in a way that could trip over this. This is an API that only works correctly given an extremely constrained pattern of use. That's fine, if unfortunate, but needs to go in the docs I think. It is essential that the pattern be - grab the lock, then 'modify' all metadata (no setTargets), then update all targets (no calls through callsites), then sync (under the lock), and that the targets *must be* stubs that grab the lock and then a) do nothing (if not lazy) or b) setTarget (under the lock), if lazy. The phases you describe are derived from this pattern and do not fall out of the API. I proposed one thing (syncTargets), and asked one question (does that obsolete setTarget). The use case Remi and you describe makes it clear that something like setTarget (with ordinary field synchronization semantics) would still have utility for two-phase callsites. It would be overkill to sync again, presuming fastpath calculation is idempotent and acceptable to do over in multiple threads. However, it's error prone, as Remi's example is broken, as you pointed out - setting the target outside of the lock means the site can (permanently) miss an update. If syncTargets were possible, you'd require no locks, and you might want something more like a CAS-based swapTarget for lazy sites. Coordination around metadata (if any) would be completely orthogonal. invariant broken (writer): { // calculate new metadata // determine new targets // update all callsites syncTargets(impacted callsites, new targets); } default generic method (reader): { // check arguments // create a fast path swapTarget(this?, guard + fastpath); } I'll leave it to your expertise whether this combination is harder to implement and harder to specify. That certainly dominates. The benefits of syncTargets and swapTarget from an API perspective are that, given appropriate regard for the expense of syncTargets - you can't get it wrong, the API itself delivers the coordination semantics, there is no elaborate pattern to replicate, and the field of use is broader. Rich From john.r.rose at oracle.com Wed Dec 15 12:08:23 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 15 Dec 2010 12:08:23 -0800 Subject: [jvm-l] Re: request for advice: safepoints in the JSR 292 spec In-Reply-To: <4D08D8F0.1040605@univ-mlv.fr> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> <4D03E13B.6000402@univ-mlv.fr> <24AB6D82-EDD5-431F-81D4-6E9C4202BC36@gmail.com> <4D05! D6FB.4020808@univ-mlv.fr> <216E098D-8930-4476-B93D-038DC422AE6F@oracle.com> <4D08! D8F0.1040605@univ-mlv.fr> Message-ID: <51F1AD14-5904-45D1-AEF5-A077980C19D3@oracle.com> On Dec 15, 2010, at 7:04 AM, R?mi Forax wrote: >>> default generic method (reader): >>> synchonized(masterLock) { >>> // check arguments >>> // use meta data to create a fast path >>> } >> (This next line should also be synchronized. -- JRR) >> >>> setTarget(guard + fastpath); > > Correct me if I'm wrong. > Le last line can be in the synchronized block but it don't have to. > The JMM guarantees that the current thread will see the new target (T2). > Other threads can see T1 and in that case will update to a T2' which is > semantically equivalent to T2. > It's a racy update. Racy updates have the risk of not getting picked up by Slow Reader threads. But, as you point out, in this case T1 synchronizes any Slow Reader and forces him to see T2. So, you're right. I guess the principle is that racy updates are OK as long as the previous state (T1) is allowed and will eventually force all readers to go to the new state (T2). -- John From richhickey at gmail.com Wed Dec 15 13:03:29 2010 From: richhickey at gmail.com (Rich Hickey) Date: Wed, 15 Dec 2010 16:03:29 -0500 Subject: [jvm-l] Re: request for advice: safepoints in the JSR 292 spec In-Reply-To: <51F1AD14-5904-45D1-AEF5-A077980C19D3@oracle.com> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <7262211E-06A0-45A8-AED1-57528EC06345@oracle.com> <4CA884F6.1090103@azulsystems.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> <4D03E13B.6000402@univ-mlv.fr> <24AB6D82-EDD5-431F-81D4-6E9C4202BC36@gmail.com> <4D05! D6FB.4020808@univ-mlv.fr> <216E098D-8930-4476-B93D-038DC422AE6F@oracle.com> <4D08! D8F0.1040605@univ-mlv.fr> <51F1AD14-5904-45D1-AEF5-A077980C19D3@oracle.com> Message-ID: On Dec 15, 2010, at 3:08 PM, John Rose wrote: > On Dec 15, 2010, at 7:04 AM, R?mi Forax wrote: > >>>> default generic method (reader): >>>> synchonized(masterLock) { >>>> // check arguments >>>> // use meta data to create a fast path >>>> } >>> (This next line should also be synchronized. -- JRR) >>> >>>> setTarget(guard + fastpath); >> >> Correct me if I'm wrong. >> Le last line can be in the synchronized block but it don't have to. >> The JMM guarantees that the current thread will see the new target >> (T2). >> Other threads can see T1 and in that case will update to a T2' >> which is >> semantically equivalent to T2. >> It's a racy update. > > Racy updates have the risk of not getting picked up by Slow Reader > threads. > > But, as you point out, in this case T1 synchronizes any Slow Reader > and forces him to see T2. > > So, you're right. > > I guess the principle is that racy updates are OK as long as the > previous state (T1) is allowed and will eventually force all readers > to go to the new state (T2). > Why can't T3 happen between the synchronized block and the setUpdate call, and get overwritten with a T1-based decision? Rich From forax at univ-mlv.fr Wed Dec 15 14:27:42 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 15 Dec 2010 23:27:42 +0100 Subject: [jvm-l] Re: request for advice: safepoints in the JSR 292 spec In-Reply-To: References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> <4D03E13B.6000402@univ-mlv.fr> <24AB6D82-EDD5-431F-81D4-6E9C4202BC36@gmail.com> <4D05! D6FB.4020808@univ-mlv.fr> <216E098D-8930-4476-B93D-038DC422AE6F@oracle.com> <4D08! D8F0.1040605@univ-mlv.fr> <51F1AD14-5904-45D1-AEF5-A077980C19D3@oracle.com> Message-ID: <4D0940DE.9020704@univ-mlv.fr> On 12/15/2010 10:03 PM, Rich Hickey wrote: > > On Dec 15, 2010, at 3:08 PM, John Rose wrote: > >> On Dec 15, 2010, at 7:04 AM, R?mi Forax wrote: >> >>>>> default generic method (reader): >>>>> synchonized(masterLock) { >>>>> // check arguments >>>>> // use meta data to create a fast path >>>>> } >>>> (This next line should also be synchronized. -- JRR) >>>> >>>>> setTarget(guard + fastpath); >>> >>> Correct me if I'm wrong. >>> Le last line can be in the synchronized block but it don't have to. >>> The JMM guarantees that the current thread will see the new target >>> (T2). >>> Other threads can see T1 and in that case will update to a T2' which is >>> semantically equivalent to T2. >>> It's a racy update. >> >> Racy updates have the risk of not getting picked up by Slow Reader >> threads. >> >> But, as you point out, in this case T1 synchronizes any Slow Reader >> and forces him to see T2. >> >> So, you're right. >> >> I guess the principle is that racy updates are OK as long as the >> previous state (T1) is allowed and will eventually force all readers >> to go to the new state (T2). >> > > Why can't T3 happen between the synchronized block and the setUpdate > call, and get overwritten with a T1-based decision? > > Rich > It can. I was wrong. setTarget() has to be in the synchronized block. R?mi From john.r.rose at oracle.com Wed Dec 15 15:27:56 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 15 Dec 2010 15:27:56 -0800 Subject: [jvm-l] Re: request for advice: safepoints in the JSR 292 spec In-Reply-To: <4D0940DE.9020704@univ-mlv.fr> References: <791C8D34-F5B9-40B1-9BB7-6A793781A7E6@oracle.com> <4CA88E8F.1010708@cs.oswego.edu> <4CA89252.4040900@azulsystems.com> <4CAD697B.6070409@azulsystems.com> <47DB50FA-AD36-4BC6-9521-00FD0B2F9B9E@oracle.com> <4CAE5F57.7090508@cs.oswego.edu> <4CB85CD8.8060108@cs.oswego.edu> <4CB871EA.2010807@azulsystems.com> <51D474E9-2C85-4A26-862A-310F2E0156B6@oracle.com> <4D02264C.206@cs.oswego.edu> <848543F4-4B7D-4B00-BE81-5845B3417866@gmail.com> <0E0244EF-1ED3-4A5F-8556-DBBD833C57AA@me.com> <4D03E13B.6000402@univ-mlv.fr> <24AB6D82-EDD5-431F-81D4-6E9C4202BC36@gmail.com> <4D05! D6FB.4020808@univ-mlv.fr> <216E098D-8930-4476-B93D-038DC422AE6F@oracle.com> <4D08! D8F0.1040605@univ-mlv.fr> <51F1AD14-5904-45D1-AEF5-A077980C19D3@oracle.com> <4D0940D! E.9020704@univ-mlv.fr> Message-ID: <568E380A-F73E-4393-BF28-823593015C95@oracle.com> On Dec 15, 2010, at 2:27 PM, R?mi Forax wrote: >> Why can't T3 happen between the synchronized block and the setUpdate call, and get overwritten with a T1-based decision? >> >> Rich >> > > It can. I was wrong. > setTarget() has to be in the synchronized block. Foo; I agree. The T1 update can float into the far future and screw things up (overwriting T3). In our EG meeting this morning we decided to provide better usage guides in the javadoc. Rich, I'm going to think a while about your alternative proposal of syncTargets and swapTarget: On Dec 15, 2010, at 9:22 AM, Rich Hickey wrote: > The benefits of syncTargets and swapTarget from an API perspective are that, given appropriate regard for the expense of syncTargets - you can't get it wrong, the API itself delivers the coordination semantics, there is no elaborate pattern to replicate, and the field of use is broader. Quick responses: SyncTargets would be a true global atomic transaction, with barriers in both directions to floating reads and writes. If you were willing to update the targets one at a time, but still wanted two-way barriers, you could use VolatileCallSite, and file a performance bug for JVMs to optimize the case of a stable volatile. The CAS idea does not translate well to function pointers, because they are necessarily opaque. (Function equivalence is undecidable...) The Object.equals method on them is pretty meaningless. I think you would need a double-CAS of some sort, which replaced a pair with a new version. I think I need a better understanding of how STM techniques are implemented on a generic JVM, and what the pain points are. -- John From john.r.rose at oracle.com Thu Dec 16 04:04:26 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 16 Dec 2010 04:04:26 -0800 Subject: review request (L): 7001424: implement JSR 292 EG adjustments, November 2010 Message-ID: This is a JDK-only change request, in response to the last several weeks of JSR 292 EG work. http://cr.openjdk.java.net/~jrose/7001424/webrev.00/ May I have an eyeball or two, please? Thanks, -- John P.S. The corresponding updated javadoc is in the usual place: http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm From john.r.rose at oracle.com Thu Dec 16 05:06:48 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 16 Dec 2010 13:06:48 +0000 Subject: hg: mlvm/mlvm/jdk: 2 new changesets Message-ID: <20101216130649.4572C47429@hg.openjdk.java.net> Changeset: ef20514fe2d7 Author: jrose Date: 2010-12-16 05:05 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ef20514fe2d7 rebase to jdk7-b121 in bsd-port ! series Changeset: 006c37860ecb Author: jrose Date: 2010-12-16 05:06 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/006c37860ecb indy, meth: roll up current EG discussions to date ! meth-api-7001424.patch From john.r.rose at oracle.com Thu Dec 16 05:07:10 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 16 Dec 2010 13:07:10 +0000 Subject: hg: mlvm/mlvm/hotspot: rebase to jdk7-b121 in bsd-port Message-ID: <20101216130711.05D574742A@hg.openjdk.java.net> Changeset: e5cc267524d7 Author: jrose Date: 2010-12-16 05:07 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/e5cc267524d7 rebase to jdk7-b121 in bsd-port ! indy-notrans-6981791.patch ! series From christian.thalinger at oracle.com Thu Dec 16 07:39:10 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 16 Dec 2010 16:39:10 +0100 Subject: review request (L): 7001424: implement JSR 292 EG adjustments, November 2010 In-Reply-To: References: Message-ID: <3F250698-D061-4C15-BCE8-FBD9504F7F1F@oracle.com> On Dec 16, 2010, at 1:04 PM, John Rose wrote: > This is a JDK-only change request, in response to the last several weeks of JSR 292 EG work. > > http://cr.openjdk.java.net/~jrose/7001424/webrev.00/ > > May I have an eyeball or two, please? > > Thanks, src/share/classes/java/dyn/ClassValue.java: 93 * If no value has yet been computed, it is obtained by 94 * by an invocation of the {@link #computeValue computeValue} method. Superfluous "by". src/share/classes/java/dyn/MethodHandle.java: 241 * This is true even if the method handle is published through a shared 242 * variables in a data race. ^variable 651 * If the implementation is faced is able to prove that an equivalent 652 * type handler call has already occurred (on the same two arguments), I'm not sure this is correct: "is faced is able" 331 *
  • If no access is allowed, the suffix is "/noaccess". 332 *
  • If only public access is allowed, the suffix is "/public". 333 *
  • If only public and package access are allowed, the suffix is "/package". 334 *
  • If only public, package, and private access are allowed, the suffix is "/private". I don't understand this. Why is the suffix "/private" if public access is allowed? src/share/classes/java/dyn/MethodType.java: 73 * in a class file's constant pool as constants. The may be loaded by an {@code ldc} "The may be" seems wrong. "They" or "The entry"? 316 * @param ptypesToInsert zero or more a new parameter types to insert after the end of the parameter list "more a new", is this correct? 533 * If a type name name is array, it the base type followed There is obviously something wrong. src/share/classes/java/dyn/package-info.java: 189 * If the resoultion succeeds, the same object reference is produced Typo. src/share/classes/java/dyn/Switcher.java: 43 * The invalidation is also permanent, which means the switcher 44 * What about the switcher? It just became interesting... ;-) -- Christian From john.r.rose at oracle.com Thu Dec 16 13:26:30 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 16 Dec 2010 13:26:30 -0800 Subject: review request (L): 7001424: implement JSR 292 EG adjustments, November 2010 In-Reply-To: <4D0A0A56.2000706@univ-mlv.fr> References: <4D0A0A56.2000706@univ-mlv.fr> Message-ID: <0EB7885A-4336-46C8-A59C-21C320964483@oracle.com> On Dec 16, 2010, at 4:47 AM, R?mi Forax wrote: > Le 16/12/2010 13:04, John Rose a ?crit : >> This is a JDK-only change request, in response to the last several weeks of JSR 292 EG work. >> >> http://cr.openjdk.java.net/~jrose/7001424/webrev.00/ >> >> May I have an eyeball or two, please? >> >> Thanks, >> -- John >> >> P.S. The corresponding updated javadoc is in the usual place: >> http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm >> > > In MethodHandles, why do you test method types using equals and not ==, > method type aren't interned anymore ? They are interned in the impl, not in the spec. I'm switching over to .equals incrementally. > In VolatileCallSite, > > invalidateAll(List sites) > should be > invalidateAll(List sites) I deleted that method (with VCS.fallback, etc.). I think there was a stale reference in Linkage. > In Switcher, invalidateAll should not use foreach: > > public static void invalidateAll(Switcher[] switchers) { > MutableCallSite[] sites = new MutableCallSite[switchers.length]; > for (int i=0; i Switcher switcher = switchers[i]; > sites[i] = switcher.mcs; > switcher.mcs.setTarget(K_false); > } > MutableCallSite.sync(sites); > } Done. -- John From john.r.rose at oracle.com Thu Dec 16 15:33:56 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 16 Dec 2010 15:33:56 -0800 Subject: review request (L): 7001424: implement JSR 292 EG adjustments, November 2010 In-Reply-To: <3F250698-D061-4C15-BCE8-FBD9504F7F1F@oracle.com> References: <3F250698-D061-4C15-BCE8-FBD9504F7F1F@oracle.com> Message-ID: <20D72EEB-0111-413B-B351-B7A081D928A3@oracle.com> Thanks, Christian. Here's the updated webrev: http://cr.openjdk.java.net/~jrose/7001424/webrev.01/ There are three code changes among the javadoc changes. Unit tests continue to pass. Responses below. -- John On Dec 16, 2010, at 7:39 AM, Christian Thalinger wrote: > On Dec 16, 2010, at 1:04 PM, John Rose wrote: >> This is a JDK-only change request, in response to the last several weeks of JSR 292 EG work. >> >> http://cr.openjdk.java.net/~jrose/7001424/webrev.00/ >> >> May I have an eyeball or two, please? >> >> Thanks, > > src/share/classes/java/dyn/ClassValue.java: > > 93 * If no value has yet been computed, it is obtained by > 94 * by an invocation of the {@link #computeValue computeValue} method. > > Superfluous "by". Fixed. > src/share/classes/java/dyn/MethodHandle.java: > > 241 * This is true even if the method handle is published through a shared > 242 * variables in a data race. > > ^variable Thanks. > 651 * If the implementation is faced is able to prove that an equivalent > 652 * type handler call has already occurred (on the same two arguments), > > I'm not sure this is correct: "is faced is able" Deleted "is faced". > 331 *
  • If no access is allowed, the suffix is "/noaccess". > 332 *
  • If only public access is allowed, the suffix is "/public". > 333 *
  • If only public and package access are allowed, the suffix is "/package". > 334 *
  • If only public, package, and private access are allowed, the suffix is "/private". > > I don't understand this. Why is the suffix "/private" if public access is allowed? If there are several permission, the highest is the one mentioned (private) not the lowest (public). It turns out that "protected" is the most restrictive. You lose that as soon as you shift views from the original lookup object, leaving only "private" at most. I'll add some clarification to the javadoc, and to the code. > src/share/classes/java/dyn/MethodType.java: > > 73 * in a class file's constant pool as constants. The may be loaded by an {@code ldc} > > "The may be" seems wrong. "They" or "The entry"? Improved: * Bytecode in the JVM can directly obtain a method handle * for any accessible method from a {@code ldc} instruction * which refers to a {@code CONSTANT_MethodHandle} constant pool entry. * (Each such entry refers directly to a {@code CONSTANT_Methodref}, * {@code CONSTANT_InterfaceMethodref}, or {@code CONSTANT_Fieldref} * constant pool entry. > 316 * @param ptypesToInsert zero or more a new parameter types to insert after the end of the parameter list > > "more a new", is this correct? Oops; deleted "a", four times. Thanks. > > 533 * If a type name name is array, it the base type followed > > There is obviously something wrong. Deleted those two lines: /** * The string representation of a method type is a * parenthesis enclosed, comma separated list of type names, * followed immediately by the return type. *

    * Each type is represented by its * {@link java.lang.Class#getSimpleName simple name}. */ @Override public String toString() { > src/share/classes/java/dyn/package-info.java: > > 189 * If the resoultion succeeds, the same object reference is produced > > Typo. Fixed. > src/share/classes/java/dyn/Switcher.java: > > 43 * The invalidation is also permanent, which means the switcher > 44 * > > What about the switcher? It just became interesting... ;-) As Remi said. Here's what I put: * The invalidation is also permanent, which means the switcher * can change state only once. * The switcher will always delegate to {@code F} after being invalidated. * At that point {@code guardWithTest} may ignore {@code T} and return {@code F}. From john.r.rose at oracle.com Thu Dec 16 17:38:37 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 17 Dec 2010 01:38:37 +0000 Subject: hg: mlvm/mlvm/jdk: meth: incorporate reviewer comments Message-ID: <20101217013838.134E74744D@hg.openjdk.java.net> Changeset: 0c547e9a6a9f Author: jrose Date: 2010-12-16 17:38 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/0c547e9a6a9f meth: incorporate reviewer comments ! meth-api-7001424.patch From lukas.stadler at jku.at Fri Dec 17 09:31:14 2010 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Fri, 17 Dec 2010 17:31:14 +0000 Subject: hg: mlvm/mlvm/hotspot: new version of the enhanced hotswapping code Message-ID: <20101217173114.422284748C@hg.openjdk.java.net> Changeset: c4bf8cbde070 Author: Thomas W??rthinger Date: 2010-12-17 18:29 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c4bf8cbde070 new version of the enhanced hotswapping code ! hotswap.patch ! hotswap.txt + hotswaplight.patch ! series From forax at univ-mlv.fr Fri Dec 17 09:42:54 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 17 Dec 2010 18:42:54 +0100 Subject: hg: mlvm/mlvm/hotspot: new version of the enhanced hotswapping code In-Reply-To: <20101217173114.422284748C@hg.openjdk.java.net> References: <20101217173114.422284748C@hg.openjdk.java.net> Message-ID: <4D0BA11E.8050501@univ-mlv.fr> Hi Lukas and/or Thomas, What's the difference between the light and the full implementations ? R?mi On 12/17/2010 06:31 PM, lukas.stadler at jku.at wrote: > Changeset: c4bf8cbde070 > Author: Thomas W??rthinger > Date: 2010-12-17 18:29 +0100 > URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c4bf8cbde070 > > new version of the enhanced hotswapping code > > ! hotswap.patch > ! hotswap.txt > + hotswaplight.patch > ! series > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101217/f536bd85/attachment.html From thomas.wuerthinger at gmail.com Fri Dec 17 09:56:06 2010 From: thomas.wuerthinger at gmail.com (Thomas Wuerthinger) Date: Fri, 17 Dec 2010 18:56:06 +0100 Subject: Enhanced HotSwapping Message-ID: <4D0BA436.5010900@gmail.com> The source code for the HotSpot version that allows enhanced hotswapping (e.g., add and remove methods, fields, and super types) was just updated in the mlvm repository. There exists now also a light version of the modifications "hotswaplight.patch" that minimizes the difference to the current OpenJDK source code by omitting some of the more advanced features (e.g., method forwarding, calling deleted old methods, transformer methods). The enhanced VM passes all tests of Oracle's class redefinition test suite and comes with unit tests for the new features. There are binary builds available from "http://ssw.jku.at/dcevm" for Mac, Linux, and Windows. So, feel free to install a VM with the new hotswapping capabilities on your machine and test them using your favorite Java IDE. - thomas From chanwit at gmail.com Fri Dec 17 20:49:02 2010 From: chanwit at gmail.com (Chanwit Kaewkasi) Date: Sat, 18 Dec 2010 11:49:02 +0700 Subject: Enhanced HotSwapping In-Reply-To: <4D0BA436.5010900@gmail.com> References: <4D0BA436.5010900@gmail.com> Message-ID: Hello Thomas, It looks cool, and thank you for binaries. Is this working through the debugger interface or JVMTI agents? Regards, Chanwit On Sat, Dec 18, 2010 at 00:56, Thomas Wuerthinger wrote: > The source code for the HotSpot version that allows enhanced hotswapping > (e.g., add and remove methods, fields, and super types) was just updated > in the mlvm repository. There exists now also a light version of the > modifications "hotswaplight.patch" that minimizes the difference to the > current OpenJDK source code by omitting some of the more advanced > features (e.g., method forwarding, calling deleted old methods, > transformer methods). The enhanced VM passes all tests of Oracle's class > redefinition test suite and comes with unit tests for the new features. > > There are binary builds available from "http://ssw.jku.at/dcevm" for > Mac, Linux, and Windows. So, feel free to install a VM with the new > hotswapping capabilities on your machine and test them using your > favorite Java IDE. > > - thomas > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Dr Chanwit Kaewkasi, Lecturer School of Computer Engineering, Suranaree University of Technology Nakhon Ratchasima, Thailand 30000 From thomas.wuerthinger at gmail.com Sat Dec 18 03:16:24 2010 From: thomas.wuerthinger at gmail.com (Thomas Wuerthinger) Date: Sat, 18 Dec 2010 12:16:24 +0100 Subject: Enhanced HotSwapping In-Reply-To: References: <4D0BA436.5010900@gmail.com> Message-ID: <4D0C9808.5000600@gmail.com> The enhanced hotswapping can be triggered using either the low-level JNI/JVMTI interface, class file transformers, or the JDWP debugger interface. There is no API change compared to the restricted hotswapping. We are currently working on providing a Java API too. In our implementation of dynamic mixins for Java (http://ssw.jku.at/dcevm/mixins/), we are using such a Java API to directly trigger the class redefinition from Java code. Our mixin implementation allows to dynamically add an interface and its implementation to an existing class. - thomas On 12/18/10 5:49 AM, Chanwit Kaewkasi wrote: > Hello Thomas, > > It looks cool, and thank you for binaries. > Is this working through the debugger interface or JVMTI agents? > > Regards, > > Chanwit > > On Sat, Dec 18, 2010 at 00:56, Thomas Wuerthinger > wrote: >> The source code for the HotSpot version that allows enhanced hotswapping >> (e.g., add and remove methods, fields, and super types) was just updated >> in the mlvm repository. There exists now also a light version of the >> modifications "hotswaplight.patch" that minimizes the difference to the >> current OpenJDK source code by omitting some of the more advanced >> features (e.g., method forwarding, calling deleted old methods, >> transformer methods). The enhanced VM passes all tests of Oracle's class >> redefinition test suite and comes with unit tests for the new features. >> >> There are binary builds available from "http://ssw.jku.at/dcevm" for >> Mac, Linux, and Windows. So, feel free to install a VM with the new >> hotswapping capabilities on your machine and test them using your >> favorite Java IDE. >> >> - thomas >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > > From jbdundas at gmail.com Sat Dec 18 10:45:54 2010 From: jbdundas at gmail.com (jitesh dundas) Date: Sun, 19 Dec 2010 00:15:54 +0530 Subject: JDK 7 changes In-Reply-To: References: Message-ID: Hello all, I have just joined. Can someone direct me to some work that I could finish in here? Appreciate your help. Regards, Jitesh Dundas From forax at univ-mlv.fr Sun Dec 19 08:09:06 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 19 Dec 2010 17:09:06 +0100 Subject: Bug when trying to find an exactInvoker ? Message-ID: <4D0E2E22.1020306@univ-mlv.fr> Is the mlvm workspace usable ? /usr/jdk/i586/jdk1.7.0/bin/java -davinci -Xbootclasspath/p:/tmp/davinci-classes.jar -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic ConvertBug VM option '+UnlockExperimentalVMOptions' VM option '+EnableInvokeDynamic' Exception in thread "main" java.lang.InternalError: JVM cannot find invoker for (double,double)double at sun.dyn.Invokers.exactInvoker(Invokers.java:74) at sun.dyn.Invokers.genericInvoker(Invokers.java:82) at java.dyn.MethodHandle.invokeWithArguments(MethodHandle.java:420) at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:468) at ConvertBug.main(ConvertBug.java:19) R?mi ----------------------------------------------------------------------------------------------------------------------------- import java.dyn.MethodHandle; import java.dyn.MethodHandles; import java.dyn.MethodType; public class ConvertBug { public static double add(double x, double y) { return x + y; } public static void main(String[] args) throws Throwable { MethodHandle mh = MethodHandles.lookup().findStatic(ConvertBug.class, "add", MethodType.methodType(double.class, double.class, double.class)); System.out.println(mh.invokeVarargs(1, 2.0)); // ok ? } } From christian.thalinger at oracle.com Mon Dec 20 02:58:03 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 20 Dec 2010 11:58:03 +0100 Subject: Spurious NPE in guardWithTest In-Reply-To: <4D07C19D.2040907@univ-mlv.fr> References: <4D07A31E.2070309@univ-mlv.fr> <4D07C19D.2040907@univ-mlv.fr> Message-ID: On Dec 14, 2010, at 8:12 PM, R?mi Forax wrote: > On 12/14/2010 06:10 PM, Christian Thalinger wrote: >> On Dec 14, 2010, at 6:02 PM, R?mi Forax wrote: >>> With the jdk7b121, sometimes when I call a MH created with guardWith, it >>> get a NPE because the target is NULL :( >>> >>> groovy examples/mixin.groovy >>> >>> java.lang.NullPointerException >>> at >>> sun.dyn.MethodHandleImpl$GuardWithTest.invoke_L1(MethodHandleImpl.java:963) >>> at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:336) >>> at org.codehaus.groovy2.lang.MOPLinker.fallback(MOPLinker.java:145) >>> at sun.dyn.FilterGeneric$F1.invoke_C0(FilterGeneric.java:516) >>> at mixin.run(Unknown Source) >>> at >>> groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:264) >>> at groovy.lang.GroovyShell.run(GroovyShell.java:227) >>> at groovy.lang.GroovyShell.run(GroovyShell.java:157) >>> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:496) >>> at groovy.ui.GroovyMain.run(GroovyMain.java:311) >>> at groovy.ui.GroovyMain.process(GroovyMain.java:297) >>> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:112) >>> at groovy.ui.GroovyMain.main(GroovyMain.java:93) >>> Caught: java.lang.NullPointerException >>> >>> Because MHs.guardWithTest() explicitly test that the target is not null, >>> I think there is a bug somewhere in the VM. >> Does it also happen with -Xint? Or C1? I guess you're using C2. > > Xint => same problem > I use C2 on a 64bits VM, I could reproduce it with C2 using a 32bits VM > but not with C1 (32bits VM). I can reproduce it on x86 and SPARC with -Xint. I'm not sure yet what causes this but can this be an API problem? -- Christian From Ulf.Zibis at gmx.de Mon Dec 20 07:02:38 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 20 Dec 2010 16:02:38 +0100 Subject: JDK 7 changes In-Reply-To: References: Message-ID: <4D0F700E.4060105@gmx.de> See: http://openjdk.java.net/contribute/ -Ulf Am 18.12.2010 19:45, schrieb jitesh dundas: > Hello all, > > I have just joined. Can someone direct me to some work that I could > finish in here? > > Appreciate your help. > > Regards, > Jitesh Dundas > From y.s.ramakrishna at oracle.com Mon Dec 20 15:31:52 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Mon, 20 Dec 2010 15:31:52 -0800 (PST) Subject: Auto Reply: Re: JDK 7 changes Message-ID: <718eae7b-9680-485b-88ef-e251137c40f7@default> This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From y.s.ramakrishna at oracle.com Mon Dec 20 15:33:19 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Mon, 20 Dec 2010 15:33:19 -0800 (PST) Subject: Auto Reply: Auto Reply: Re: JDK 7 changes Message-ID: <91beab5c-7a0f-4a71-9fc0-7a651cf05af5@default> This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From john.r.rose at oracle.com Mon Dec 20 16:10:46 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 20 Dec 2010 16:10:46 -0800 Subject: Spurious NPE in guardWithTest In-Reply-To: References: <4D07A31E.2070309@univ-mlv.fr> <4D07C19D.2040907@univ-mlv.fr> Message-ID: On Dec 20, 2010, at 2:58 AM, Christian Thalinger wrote: > I can reproduce it on x86 and SPARC with -Xint. I'm not sure yet what causes this but can this be an API problem? Could be a problem with a generic invoker, I suppose. Generic invocation is relatively new code. Remi, what's the type of the receiver of invokeWithArguments (invokeVarargs)? -- John From y.s.ramakrishna at oracle.com Mon Dec 20 16:12:00 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Mon, 20 Dec 2010 16:12:00 -0800 (PST) Subject: Auto Reply: Re: Spurious NPE in guardWithTest Message-ID: <22541985-aea3-487f-a2d5-838a91c87c47@default> This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From forax at univ-mlv.fr Mon Dec 20 23:53:15 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 21 Dec 2010 08:53:15 +0100 Subject: Bug when trying to find an exactInvoker ? [Was]: Spurious NPE in guardWithTest In-Reply-To: References: <4D07A31E.2070309@univ-mlv.fr> <4D07C19D.2040907@univ-mlv.fr> Message-ID: <4D105CEB.6070802@univ-mlv.fr> John, there are two different bugs: One throws a NPE when calling a guardWithTest, the other can't get the exactInvoker when calling invokeWithArguments() and is only reproductible with mlvm workspace code. Basically, lookup.findVirtual(MethodHandle.class, "invoke", methodType) fails. R?mi On 12/19/2010 05:09 PM, R?mi Forax wrote: > Is the mlvm workspace usable ? > > /usr/jdk/i586/jdk1.7.0/bin/java -davinci > -Xbootclasspath/p:/tmp/davinci-classes.jar > -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic ConvertBug > VM option '+UnlockExperimentalVMOptions' > VM option '+EnableInvokeDynamic' > Exception in thread "main" java.lang.InternalError: JVM cannot find > invoker for (double,double)double > at sun.dyn.Invokers.exactInvoker(Invokers.java:74) > at sun.dyn.Invokers.genericInvoker(Invokers.java:82) > at java.dyn.MethodHandle.invokeWithArguments(MethodHandle.java:420) > at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:468) > at ConvertBug.main(ConvertBug.java:19) > > R?mi > > ----------------------------------------------------------------------------------------------------------------------------- > > import java.dyn.MethodHandle; > import java.dyn.MethodHandles; > import java.dyn.MethodType; > > public class ConvertBug { > public static double add(double x, double y) { > return x + y; > } > > public static void main(String[] args) throws Throwable { > MethodHandle mh = > MethodHandles.lookup().findStatic(ConvertBug.class, "add", > MethodType.methodType(double.class, double.class, double.class)); > System.out.println(mh.invokeVarargs(1, 2.0)); // ok ? > } > } > > On 12/21/2010 01:10 AM, John Rose wrote: > On Dec 20, 2010, at 2:58 AM, Christian Thalinger wrote: > >> I can reproduce it on x86 and SPARC with -Xint. I'm not sure yet what causes this but can this be an API problem? > Could be a problem with a generic invoker, I suppose. Generic invocation is relatively new code. > > Remi, what's the type of the receiver of invokeWithArguments (invokeVarargs)? > > -- John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From y.s.ramakrishna at oracle.com Mon Dec 20 23:57:06 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Mon, 20 Dec 2010 23:57:06 -0800 (PST) Subject: Auto Reply: Re: Bug when trying to find an exactInvoker ? [Was]: Spurious NPE in guardWithTest Message-ID: <11427258-2675-441b-87e0-a79dde5ee522@default> This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From lukas.stadler at jku.at Tue Dec 21 08:18:42 2010 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Tue, 21 Dec 2010 16:18:42 +0000 Subject: hg: mlvm/mlvm/hotspot: coro: experimental coroutine thread migration and serialization Message-ID: <20101221161842.A8F034757F@hg.openjdk.java.net> Changeset: e09236f9d880 Author: Lukas Stadler Date: 2010-12-21 17:17 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/e09236f9d880 coro: experimental coroutine thread migration and serialization ! coro.patch From lukas.stadler at jku.at Tue Dec 21 08:18:56 2010 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Tue, 21 Dec 2010 16:18:56 +0000 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: <20101221161856.1D01847580@hg.openjdk.java.net> Changeset: b7b61c41e164 Author: Lukas Stadler Date: 2010-12-21 17:18 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/b7b61c41e164 coro: experimental coroutine thread migration and serialization ! coro.patch From y.s.ramakrishna at oracle.com Tue Dec 21 08:19:42 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Tue, 21 Dec 2010 08:19:42 -0800 (PST) Subject: Auto Reply: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: <5083a295-acdc-4d37-9b3d-1a4266e22c24@default> This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From xuanxi at taobao.com Wed Dec 22 00:41:43 2010 From: xuanxi at taobao.com (=?gb2312?B?0P7Pow==?=) Date: Wed, 22 Dec 2010 16:41:43 +0800 Subject: =?gb2312?B?tPC4tDogRW5oYW5jZWQgSG90U3dhcHBpbmc=?= In-Reply-To: <4D0C9808.5000600@gmail.com> References: <4D0BA436.5010900@gmail.com> <4D0C9808.5000600@gmail.com> Message-ID: <36B1E8E5B3C60F4EBF81CA77BD85DCC0646AEFBA8A@CNHZ-EXCMS-04.ali.com> Hi, the HotSwap.patch is amazing work. We expressed regarding this is excited?? We try it on windows for debug our application?? But some errors happen?? We use jre 1.6.0_23. 1,when we load eclipse eclipse often alert permgen OOM?? 2??when we load jboss??jboss often crash??The jvm erro message are in the attachment?? Would you tell me how to solve this?? -----????????----- ??????: mlvm-dev-bounces at openjdk.java.net [mailto:mlvm-dev-bounces at openjdk.java.net] ???? Thomas Wuerthinger ????????: 2010??12??18?? 19:16 ??????: Da Vinci Machine Project ????: Re: Enhanced HotSwapping The enhanced hotswapping can be triggered using either the low-level JNI/JVMTI interface, class file transformers, or the JDWP debugger interface. There is no API change compared to the restricted hotswapping. We are currently working on providing a Java API too. In our implementation of dynamic mixins for Java (http://ssw.jku.at/dcevm/mixins/), we are using such a Java API to directly trigger the class redefinition from Java code. Our mixin implementation allows to dynamically add an interface and its implementation to an existing class. - thomas On 12/18/10 5:49 AM, Chanwit Kaewkasi wrote: > Hello Thomas, > > It looks cool, and thank you for binaries. > Is this working through the debugger interface or JVMTI agents? > > Regards, > > Chanwit > > On Sat, Dec 18, 2010 at 00:56, Thomas Wuerthinger > wrote: >> The source code for the HotSpot version that allows enhanced hotswapping >> (e.g., add and remove methods, fields, and super types) was just updated >> in the mlvm repository. There exists now also a light version of the >> modifications "hotswaplight.patch" that minimizes the difference to the >> current OpenJDK source code by omitting some of the more advanced >> features (e.g., method forwarding, calling deleted old methods, >> transformer methods). The enhanced VM passes all tests of Oracle's class >> redefinition test suite and comes with unit tests for the new features. >> >> There are binary builds available from "http://ssw.jku.at/dcevm" for >> Mac, Linux, and Windows. So, feel free to install a VM with the new >> hotswapping capabilities on your machine and test them using your >> favorite Java IDE. >> >> - thomas >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > > _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid1340.log Type: application/octet-stream Size: 33492 bytes Desc: hs_err_pid1340.log Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101222/a8766b48/attachment-0001.obj From y.s.ramakrishna at oracle.com Wed Dec 22 00:42:45 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Wed, 22 Dec 2010 00:42:45 -0800 (PST) Subject: =?UTF-8?B?QXV0byBSZXBseTog562U5aSNOiBFbmhhbmNlZCBIb3RTd2FwcGluZw==?= Message-ID: <95952444-6e81-49c2-ba1a-4213e1358dfe@default> This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From thomas.wuerthinger at gmail.com Wed Dec 22 03:20:47 2010 From: thomas.wuerthinger at gmail.com (Thomas Wuerthinger) Date: Wed, 22 Dec 2010 12:20:47 +0100 Subject: =?GB2312?B?tPC4tDogRW5oYW5jZWQgSG90U3dhcHBpbmc=?= In-Reply-To: <36B1E8E5B3C60F4EBF81CA77BD85DCC0646AEFBA8A@CNHZ-EXCMS-04.ali.com> References: <4D0BA436.5010900@gmail.com> <4D0C9808.5000600@gmail.com> <36B1E8E5B3C60F4EBF81CA77BD85DCC0646AEFBA8A@CNHZ-EXCMS-04.ali.com> Message-ID: <4D11DF0F.4040401@gmail.com> The attached crash happend when using the standard HotSpot and not the DCE VM. The version string says "Java HotSpot(TM) Server VM" and not "Dynamic Code Evolution 64-Bit Server VM", so it cannot be an issue related to the DCE VM. Most likely the same applies to the first issue (try to increase permanent generation size with for example -XX:MaxPermSize=512m). Please report bugs of the DCE VM at http://ssw.jku.at/dcevm/bugtracking/ as suggested in the crash dumps of the VM. - thomas On 12/22/2010 09:41 AM, ???? wrote: > Hi, the HotSwap.patch is amazing work. We expressed regarding this is excited?? We try it on windows for debug our application?? > But some errors happen?? > We use jre 1.6.0_23. > 1,when we load eclipse eclipse often alert permgen OOM?? > 2??when we load jboss??jboss often crash??The jvm erro message are in the attachment?? > > Would you tell me how to solve this?? > > -----????????----- > ??????: mlvm-dev-bounces at openjdk.java.net [mailto:mlvm-dev-bounces at openjdk.java.net] ???? Thomas Wuerthinger > ????????: 2010??12??18?? 19:16 > ??????: Da Vinci Machine Project > ????: Re: Enhanced HotSwapping > > The enhanced hotswapping can be triggered using either the low-level > JNI/JVMTI interface, class file transformers, or the JDWP debugger > interface. There is no API change compared to the restricted hotswapping. > > We are currently working on providing a Java API too. In our > implementation of dynamic mixins for Java > (http://ssw.jku.at/dcevm/mixins/), we are using such a Java API to > directly trigger the class redefinition from Java code. Our mixin > implementation allows to dynamically add an interface and its > implementation to an existing class. > > - thomas > > > > On 12/18/10 5:49 AM, Chanwit Kaewkasi wrote: >> Hello Thomas, >> >> It looks cool, and thank you for binaries. >> Is this working through the debugger interface or JVMTI agents? >> >> Regards, >> >> Chanwit >> >> On Sat, Dec 18, 2010 at 00:56, Thomas Wuerthinger >> wrote: >>> The source code for the HotSpot version that allows enhanced hotswapping >>> (e.g., add and remove methods, fields, and super types) was just updated >>> in the mlvm repository. There exists now also a light version of the >>> modifications "hotswaplight.patch" that minimizes the difference to the >>> current OpenJDK source code by omitting some of the more advanced >>> features (e.g., method forwarding, calling deleted old methods, >>> transformer methods). The enhanced VM passes all tests of Oracle's class >>> redefinition test suite and comes with unit tests for the new features. >>> >>> There are binary builds available from "http://ssw.jku.at/dcevm" for >>> Mac, Linux, and Windows. So, feel free to install a VM with the new >>> hotswapping capabilities on your machine and test them using your >>> favorite Java IDE. >>> >>> - thomas >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. > > ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101222/5ae8e048/attachment.html From y.s.ramakrishna at oracle.com Wed Dec 22 03:21:26 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Wed, 22 Dec 2010 03:21:26 -0800 (PST) Subject: =?UTF-8?B?QXV0byBSZXBseTogUmU6IOetlOWkjTogRW5oYW5jZWQgSG90U3dhcHBpbmc=?= Message-ID: <14208f4a-3f6b-4d84-85a7-0830c758ec31@default> This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From stephen.bannasch at deanbrook.org Wed Dec 22 11:13:25 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 22 Dec 2010 14:13:25 -0500 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: <20101221161856.1D01847580@hg.openjdk.java.net> References: <20101221161856.1D01847580@hg.openjdk.java.net> Message-ID: fyi: coro now builds on my Mac OS X 10.6.5 system thanks From y.s.ramakrishna at oracle.com Wed Dec 22 11:14:32 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Wed, 22 Dec 2010 11:14:32 -0800 (PST) Subject: Auto Reply: Re: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: <0707466a-948d-4f8e-892d-ad7ad342e03a@default> This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From headius at headius.com Wed Dec 22 14:47:05 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 22 Dec 2010 16:47:05 -0600 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: References: <20101221161856.1D01847580@hg.openjdk.java.net> Message-ID: Got a build you can publish for those of us following along at home? :) On Wed, Dec 22, 2010 at 1:13 PM, Stephen Bannasch wrote: > fyi: coro now builds on my Mac OS X 10.6.5 system > > thanks > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From y.s.ramakrishna at oracle.com Wed Dec 22 14:48:10 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Wed, 22 Dec 2010 14:48:10 -0800 (PST) Subject: Auto Reply: Re: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From jlaskey at me.com Wed Dec 22 14:48:47 2010 From: jlaskey at me.com (Jim Laskey) Date: Wed, 22 Dec 2010 18:48:47 -0400 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: References: <20101221161856.1D01847580@hg.openjdk.java.net> Message-ID: +1 On 2010-12-22, at 6:47 PM, Charles Oliver Nutter wrote: > Got a build you can publish for those of us following along at home? :) > > On Wed, Dec 22, 2010 at 1:13 PM, Stephen Bannasch > wrote: >> fyi: coro now builds on my Mac OS X 10.6.5 system >> >> thanks >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From y.s.ramakrishna at oracle.com Wed Dec 22 14:49:33 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Wed, 22 Dec 2010 14:49:33 -0800 (PST) Subject: Auto Reply: Re: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From stephen.bannasch at deanbrook.org Wed Dec 22 16:37:03 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 22 Dec 2010 19:37:03 -0500 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: References: <20101221161856.1D01847580@hg.openjdk.java.net> Message-ID: At 4:47 PM -0600 12/22/10, Charles Oliver Nutter wrote: >Got a build you can publish for those of us following along at home? :) Here you go! http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-mlvm-2010_12_22.tar.gz I'll help anyway I can to get fast co-routines integrated into JRuby! From xuanxi at taobao.com Wed Dec 22 17:35:01 2010 From: xuanxi at taobao.com (=?gb2312?B?0P7Pow==?=) Date: Thu, 23 Dec 2010 09:35:01 +0800 Subject: =?gb2312?B?tPC4tDogtPC4tDogRW5oYW5jZWQgSG90U3dhcHBpbmc=?= In-Reply-To: <4D11DF0F.4040401@gmail.com> References: <4D0BA436.5010900@gmail.com> <4D0C9808.5000600@gmail.com> <36B1E8E5B3C60F4EBF81CA77BD85DCC0646AEFBA8A@CNHZ-EXCMS-04.ali.com> <4D11DF0F.4040401@gmail.com> Message-ID: <36B1E8E5B3C60F4EBF81CA77BD85DCC0646AEFBBE0@CNHZ-EXCMS-04.ali.com> Thx??but the eclipse report PermGen OOM was use the DCE VM. We aready set -XX:MaxPermSize=512m.the bug is here. http://kenai.com/jira/browse/DCEVM-1 By the way??our company has more than two thousands java developer??we can't wait to use this functions in our the development process?? ??????: mlvm-dev-bounces at openjdk.java.net [mailto:mlvm-dev-bounces at openjdk.java.net] ???? Thomas Wuerthinger ????????: 2010??12??22?? 19:21 ??????: Da Vinci Machine Project ????: Re: ????: Enhanced HotSwapping The attached crash happend when using the standard HotSpot and not the DCE VM. The version string says "Java HotSpot(TM) Server VM" and not "Dynamic Code Evolution 64-Bit Server VM", so it cannot be an issue related to the DCE VM. Most likely the same applies to the first issue (try to increase permanent generation size with for example -XX:MaxPermSize=512m). Please report bugs of the DCE VM at http://ssw.jku.at/dcevm/bugtracking/ as suggested in the crash dumps of the VM. - thomas On 12/22/2010 09:41 AM, ???? wrote: Hi, the HotSwap.patch is amazing work. We expressed regarding this is excited?? We try it on windows for debug our application?? But some errors happen?? We use jre 1.6.0_23. 1,when we load eclipse eclipse often alert permgen OOM?? 2??when we load jboss??jboss often crash??The jvm erro message are in the attachment?? Would you tell me how to solve this?? -----????????----- ??????: mlvm-dev-bounces at openjdk.java.net [mailto:mlvm-dev-bounces at openjdk.java.net] ???? Thomas Wuerthinger ????????: 2010??12??18?? 19:16 ??????: Da Vinci Machine Project ????: Re: Enhanced HotSwapping The enhanced hotswapping can be triggered using either the low-level JNI/JVMTI interface, class file transformers, or the JDWP debugger interface. There is no API change compared to the restricted hotswapping. We are currently working on providing a Java API too. In our implementation of dynamic mixins for Java (http://ssw.jku.at/dcevm/mixins/), we are using such a Java API to directly trigger the class redefinition from Java code. Our mixin implementation allows to dynamically add an interface and its implementation to an existing class. - thomas On 12/18/10 5:49 AM, Chanwit Kaewkasi wrote: Hello Thomas, It looks cool, and thank you for binaries. Is this working through the debugger interface or JVMTI agents? Regards, Chanwit On Sat, Dec 18, 2010 at 00:56, Thomas Wuerthinger wrote: The source code for the HotSpot version that allows enhanced hotswapping (e.g., add and remove methods, fields, and super types) was just updated in the mlvm repository. There exists now also a light version of the modifications "hotswaplight.patch" that minimizes the difference to the current OpenJDK source code by omitting some of the more advanced features (e.g., method forwarding, calling deleted old methods, transformer methods). The enhanced VM passes all tests of Oracle's class redefinition test suite and comes with unit tests for the new features. There are binary builds available from "http://ssw.jku.at/dcevm" for Mac, Linux, and Windows. So, feel free to install a VM with the new hotswapping capabilities on your machine and test them using your favorite Java IDE. - thomas _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you. ??????(????????????)???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101223/debe9517/attachment-0001.html From howard.lovatt at gmail.com Wed Dec 22 22:09:23 2010 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Thu, 23 Dec 2010 17:09:23 +1100 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: Hi, When I use this version on my lambda test code I get the following error: VM option '+UnlockExperimentalVMOptions' VM option '+EnableMethodHandles' VM option '+EnableInvokeDynamic' VM option 'SuppressErrorAt=/constantPoolOop.cpp:283' # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_x86.inline.hpp:38 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/cpu/x86/vm/assembler_x86.inline.hpp:38), pid=22339, tid=4298117120 # guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset # # JRE version: 7.0 # Java VM: OpenJDK 64-Bit Server VM (20.0-b03-fastdebug mixed mode bsd-amd64 compressed oops) # An error report file with more information is saved as: # /Users/lov080/Dropbox/Personal/Java/examples/Lambdas/build/classes/hs_err_pid22339.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Current thread is 4298117120 Dumping core ... ./cr: line 18: 22339 Abort trap $jdk/java -cp .:$guava:$javac -ea -Xfuture -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic -XX:SuppressErrorAt=/constantPoolOop.cpp:283 $package.Main I can give more info if required to help debug the problem. Thanks for making a Mac build available. ? -- Howard. From y.s.ramakrishna at oracle.com Wed Dec 22 22:10:40 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Wed, 22 Dec 2010 22:10:40 -0800 (PST) Subject: Auto Reply: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: <077b3ae8-6550-45ad-a74c-1adf72988602@default> This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From john.r.rose at oracle.com Wed Dec 22 22:30:25 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 22 Dec 2010 22:30:25 -0800 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: References: Message-ID: <0E1E0696-79C4-4CEC-BCA9-9CC3332E2EA9@oracle.com> Can you get a backtrace? The question is who is torturing the poor assembler. -- John On Dec 22, 2010, at 10:09 PM, Howard Lovatt wrote: > Hi, > > When I use this version on my lambda test code I get the following error: > > VM option '+UnlockExperimentalVMOptions' > VM option '+EnableMethodHandles' > VM option '+EnableInvokeDynamic' > VM option 'SuppressErrorAt=/constantPoolOop.cpp:283' > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_x86.inline.hpp:38 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/cpu/x86/vm/assembler_x86.inline.hpp:38), > pid=22339, tid=4298117120 > # guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset > # > # JRE version: 7.0 > # Java VM: OpenJDK 64-Bit Server VM (20.0-b03-fastdebug mixed mode > bsd-amd64 compressed oops) > # An error report file with more information is saved as: > # /Users/lov080/Dropbox/Personal/Java/examples/Lambdas/build/classes/hs_err_pid22339.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Current thread is 4298117120 > Dumping core ... > ./cr: line 18: 22339 Abort trap $jdk/java -cp > .:$guava:$javac -ea -Xfuture -XX:+UnlockExperimentalVMOptions > -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic > -XX:SuppressErrorAt=/constantPoolOop.cpp:283 $package.Main > > I can give more info if required to help debug the problem. > > Thanks for making a Mac build available. > > -- Howard. > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From christian.thalinger at oracle.com Thu Dec 23 00:37:57 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 23 Dec 2010 09:37:57 +0100 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: <0E1E0696-79C4-4CEC-BCA9-9CC3332E2EA9@oracle.com> References: <0E1E0696-79C4-4CEC-BCA9-9CC3332E2EA9@oracle.com> Message-ID: <9916D13E-FB20-4E8F-A8FE-BA25CAEB17EE@oracle.com> Yeah, the hs_err file would help here. -- Christian On Dec 23, 2010, at 7:30 AM, John Rose wrote: > Can you get a backtrace? The question is who is torturing the poor assembler. -- John > > On Dec 22, 2010, at 10:09 PM, Howard Lovatt wrote: > >> Hi, >> >> When I use this version on my lambda test code I get the following error: >> >> VM option '+UnlockExperimentalVMOptions' >> VM option '+EnableMethodHandles' >> VM option '+EnableInvokeDynamic' >> VM option 'SuppressErrorAt=/constantPoolOop.cpp:283' >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_x86.inline.hpp:38 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error >> (/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/cpu/x86/vm/assembler_x86.inline.hpp:38), >> pid=22339, tid=4298117120 >> # guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK 64-Bit Server VM (20.0-b03-fastdebug mixed mode >> bsd-amd64 compressed oops) >> # An error report file with more information is saved as: >> # /Users/lov080/Dropbox/Personal/Java/examples/Lambdas/build/classes/hs_err_pid22339.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> Current thread is 4298117120 >> Dumping core ... >> ./cr: line 18: 22339 Abort trap $jdk/java -cp >> .:$guava:$javac -ea -Xfuture -XX:+UnlockExperimentalVMOptions >> -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic >> -XX:SuppressErrorAt=/constantPoolOop.cpp:283 $package.Main >> >> I can give more info if required to help debug the problem. >> >> Thanks for making a Mac build available. >> >> -- Howard. >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From jlaskey at me.com Thu Dec 23 03:09:29 2010 From: jlaskey at me.com (Jim Laskey) Date: Thu, 23 Dec 2010 07:09:29 -0400 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: <9916D13E-FB20-4E8F-A8FE-BA25CAEB17EE@oracle.com> References: <0E1E0696-79C4-4CEC-BCA9-9CC3332E2EA9@oracle.com> <9916D13E-FB20-4E8F-A8FE-BA25CAEB17EE@oracle.com> Message-ID: <87AE274A-62E1-401F-B7E3-5CCD64278F5B@me.com> I ran into a similar problem. run: # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_x86.inline.hpp:38 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/cpu/x86/vm/assembler_x86.inline.hpp:38), pid=41614, tid=4298117120 # guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset # # JRE version: 7.0 # Java VM: OpenJDK 64-Bit Server VM (20.0-b03-fastdebug mixed mode bsd-amd64 compressed oops) # An error report file with more information is saved as: # /Projects/nashorn~source/nashorn/hs_err_pid41614.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # VM option '+UnlockExperimentalVMOptions' VM option '+EnableMethodHandles' VM option '+EnableInvokeDynamic' Current thread is 4298117120 Dumping core ... Thread 1 Crashed: 0 libSystem.B.dylib 0x00007fff87d86669 usleep$NOCANCEL + 0 1 libSystem.B.dylib 0x00007fff87da5cd4 abort + 93 2 libjvm.dylib 0x000000010101856c os::abort(bool) + 236 3 libjvm.dylib 0x000000010101fc91 VMError::report_and_die() + 1377 4 libjvm.dylib 0x000000010100bba4 report_vm_error(char const*, int, char const*, char const*) + 132 5 libjvm.dylib 0x00000001011a3f20 Label::patch_instructions(MacroAssembler*) + 624 6 libjvm.dylib 0x0000000101973862 MethodHandles::verify_klass(MacroAssembler*, RegisterImpl*, KlassHandle, char const*) + 1362 7 libjvm.dylib 0x0000000101973aec MethodHandles::load_klass_from_Class(MacroAssembler*, RegisterImpl*) + 108 8 libjvm.dylib 0x0000000101979eea MethodHandles::generate_method_handle_stub(MacroAssembler*, MethodHandles::EntryKind) + 4346 9 libjvm.dylib 0x00000001019617cb MethodHandles::generate_adapters() + 427 10 libjvm.dylib 0x000000010161ccb4 init_globals() + 260 11 libjvm.dylib 0x0000000101bd3a0d Threads::create_vm(JavaVMInitArgs*, bool*) + 573 12 libjvm.dylib 0x00000001016a8f8b JNI_CreateJavaVM + 155 13 java 0x00000001000022e7 JavaMain + 167 14 libSystem.B.dylib 0x00007fff87cf0536 _pthread_start + 331 15 libSystem.B.dylib 0x00007fff87cf03e9 thread_start + 13 Including hs_err -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid41614.log Type: application/octet-stream Size: 5114 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101223/831b2da7/attachment.obj -------------- next part -------------- Cheers, -- Jim On 2010-12-23, at 4:37 AM, Christian Thalinger wrote: > Yeah, the hs_err file would help here. -- Christian > > On Dec 23, 2010, at 7:30 AM, John Rose wrote: >> Can you get a backtrace? The question is who is torturing the poor assembler. -- John >> >> On Dec 22, 2010, at 10:09 PM, Howard Lovatt wrote: >> >>> Hi, >>> >>> When I use this version on my lambda test code I get the following error: >>> >>> VM option '+UnlockExperimentalVMOptions' >>> VM option '+EnableMethodHandles' >>> VM option '+EnableInvokeDynamic' >>> VM option 'SuppressErrorAt=/constantPoolOop.cpp:283' >>> # To suppress the following error report, specify this argument >>> # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_x86.inline.hpp:38 >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error >>> (/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/cpu/x86/vm/assembler_x86.inline.hpp:38), >>> pid=22339, tid=4298117120 >>> # guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset >>> # >>> # JRE version: 7.0 >>> # Java VM: OpenJDK 64-Bit Server VM (20.0-b03-fastdebug mixed mode >>> bsd-amd64 compressed oops) >>> # An error report file with more information is saved as: >>> # /Users/lov080/Dropbox/Personal/Java/examples/Lambdas/build/classes/hs_err_pid22339.log >>> # >>> # If you would like to submit a bug report, please visit: >>> # http://java.sun.com/webapps/bugreport/crash.jsp >>> # >>> Current thread is 4298117120 >>> Dumping core ... >>> ./cr: line 18: 22339 Abort trap $jdk/java -cp >>> .:$guava:$javac -ea -Xfuture -XX:+UnlockExperimentalVMOptions >>> -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic >>> -XX:SuppressErrorAt=/constantPoolOop.cpp:283 $package.Main >>> >>> I can give more info if required to help debug the problem. >>> >>> Thanks for making a Mac build available. >>> >>> -- Howard. >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From christian.thalinger at oracle.com Thu Dec 23 03:36:23 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 23 Dec 2010 12:36:23 +0100 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: <87AE274A-62E1-401F-B7E3-5CCD64278F5B@me.com> References: <0E1E0696-79C4-4CEC-BCA9-9CC3332E2EA9@oracle.com> <9916D13E-FB20-4E8F-A8FE-BA25CAEB17EE@oracle.com> <87AE274A-62E1-401F-B7E3-5CCD64278F5B@me.com> Message-ID: On Dec 23, 2010, at 12:09 PM, Jim Laskey wrote: > I ran into a similar problem. > > > run: > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_x86.inline.hpp:38 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/Users/stephen/dev/java/src/mlvm/sources/hotspot/src/cpu/x86/vm/assembler_x86.inline.hpp:38), pid=41614, tid=4298117120 > # guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset > # > # JRE version: 7.0 > # Java VM: OpenJDK 64-Bit Server VM (20.0-b03-fastdebug mixed mode bsd-amd64 compressed oops) > # An error report file with more information is saved as: > # /Projects/nashorn~source/nashorn/hs_err_pid41614.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > VM option '+UnlockExperimentalVMOptions' > VM option '+EnableMethodHandles' > VM option '+EnableInvokeDynamic' > Current thread is 4298117120 > Dumping core ... > > Thread 1 Crashed: > 0 libSystem.B.dylib 0x00007fff87d86669 usleep$NOCANCEL + 0 > 1 libSystem.B.dylib 0x00007fff87da5cd4 abort + 93 > 2 libjvm.dylib 0x000000010101856c os::abort(bool) + 236 > 3 libjvm.dylib 0x000000010101fc91 VMError::report_and_die() + 1377 > 4 libjvm.dylib 0x000000010100bba4 report_vm_error(char const*, int, char const*, char const*) + 132 > 5 libjvm.dylib 0x00000001011a3f20 Label::patch_instructions(MacroAssembler*) + 624 > 6 libjvm.dylib 0x0000000101973862 MethodHandles::verify_klass(MacroAssembler*, RegisterImpl*, KlassHandle, char const*) + 1362 > 7 libjvm.dylib 0x0000000101973aec MethodHandles::load_klass_from_Class(MacroAssembler*, RegisterImpl*) + 108 > 8 libjvm.dylib 0x0000000101979eea MethodHandles::generate_method_handle_stub(MacroAssembler*, MethodHandles::EntryKind) + 4346 > 9 libjvm.dylib 0x00000001019617cb MethodHandles::generate_adapters() + 427 > 10 libjvm.dylib 0x000000010161ccb4 init_globals() + 260 > 11 libjvm.dylib 0x0000000101bd3a0d Threads::create_vm(JavaVMInitArgs*, bool*) + 573 > 12 libjvm.dylib 0x00000001016a8f8b JNI_CreateJavaVM + 155 > 13 java 0x00000001000022e7 JavaMain + 167 > 14 libSystem.B.dylib 0x00007fff87cf0536 _pthread_start + 331 > 15 libSystem.B.dylib 0x00007fff87cf03e9 thread_start + 13 That seems to be a problem in meth-conv-6939861. MethodHandles::verify_klass should use jcc instead of jccb. John, will you fix it or should I take care of it? -- Christian From lukas.stadler at jku.at Thu Dec 23 07:09:21 2010 From: lukas.stadler at jku.at (Lukas Stadler) Date: Thu, 23 Dec 2010 16:09:21 +0100 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: <20101221161856.1D01847580@hg.openjdk.java.net> References: <20101221161856.1D01847580@hg.openjdk.java.net> Message-ID: <4D136621.1010102@jku.at> Maybe I should say a few words about what I did... First of all I changed a few details of how the coroutine stacks are walked during gc, which should make the coroutine code more reliable. Other than that, there are three new methods in CoroutineSupport: * public boolean stealCoroutine(CoroutineBase coroutine) This method can be used to "steal" a coroutine from another thread. It seemed the most natural to me that the thread that the coroutine should be transferred to initiates the transfer, that way a thread that is idle can "steal" a coroutine. (this took a little inspiration from the fork/join framework...) The transfer can fail for a number of reasons, e.g. if the coroutine is currently running or if the current thread already owns the coroutine. "stupid" things like trying to steal from the current thread will throw an exception, otherwise the success is reported as the boolean return value. * public CoroutineFrame[] serializeCoroutine(CoroutineBase coroutine) Returns the java frames of the specified coroutine as an array of CoroutineFrame. This is a rough prototype of how this should work, the returned frames include frames that an application should not be able to change. for (CoroutineFrame frame: hread.currentThread().getCoroutineSupport().serializeCoroutine(coroutine)) frame.dump(); * public void replaceCoroutine(CoroutineBase coroutine, CoroutineFrame[] frames) Replaces the given coroutine's contents with the given frames. There is no checking of the given stackframes whatsoever! The serialization/deserialization could be used to replace an interpreter loop with a compiled method, kind of Java-OSR - that would be neat... cheers, Lukas On 21.12.2010 17:18, lukas.stadler at jku.at wrote: > Changeset: b7b61c41e164 > Author: Lukas Stadler > Date: 2010-12-21 17:18 +0100 > URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/b7b61c41e164 > > coro: experimental coroutine thread migration and serialization > > ! coro.patch > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From y.s.ramakrishna at oracle.com Thu Dec 23 07:10:13 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Thu, 23 Dec 2010 07:10:13 -0800 (PST) Subject: Auto Reply: Re: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From forax at univ-mlv.fr Thu Dec 23 11:52:01 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 23 Dec 2010 20:52:01 +0100 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: <4D136621.1010102@jku.at> References: <20101221161856.1D01847580@hg.openjdk.java.net> <4D136621.1010102@jku.at> Message-ID: <4D13A861.8090807@univ-mlv.fr> On 12/23/2010 04:09 PM, Lukas Stadler wrote: > Maybe I should say a few words about what I did... > First of all I changed a few details of how the coroutine stacks are > walked during gc, which should make the coroutine code more reliable. > > Other than that, there are three new methods in CoroutineSupport: > * public boolean stealCoroutine(CoroutineBase coroutine) > This method can be used to "steal" a coroutine from another thread. It > seemed the most natural to me that the thread that the coroutine should > be transferred to initiates the transfer, that way a thread that is idle > can "steal" a coroutine. (this took a little inspiration from the > fork/join framework...) > The transfer can fail for a number of reasons, e.g. if the coroutine is > currently running or if the current thread already owns the coroutine. > "stupid" things like trying to steal from the current thread will throw > an exception, otherwise the success is reported as the boolean return value. > > * public CoroutineFrame[] serializeCoroutine(CoroutineBase coroutine) > Returns the java frames of the specified coroutine as an array of > CoroutineFrame. This is a rough prototype of how this should work, the > returned frames include frames that an application should not be able to > change. > > for (CoroutineFrame frame: > hread.currentThread().getCoroutineSupport().serializeCoroutine(coroutine)) > frame.dump(); > > * public void replaceCoroutine(CoroutineBase coroutine, CoroutineFrame[] > frames) > Replaces the given coroutine's contents with the given frames. There is > no checking of the given stackframes whatsoever! > > The serialization/deserialization could be used to replace an > interpreter loop with a compiled method, kind of Java-OSR - that would > be neat... clearly neat :) I want to do the opposite i.e. generate a compiled code that bailout to an interpreter if by example a + overflow. How can I read the CoroutineFrame object to reconstitute the stack ? > cheers, > Lukas > R?mi From john.r.rose at oracle.com Thu Dec 23 14:20:42 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 23 Dec 2010 22:20:42 +0000 Subject: hg: mlvm/mlvm/jdk: meth, indy: reflect pushes to hotspot-comp Message-ID: <20101223222042.32AF5476CB@hg.openjdk.java.net> Changeset: 25775fb03e15 Author: jrose Date: 2010-12-23 14:20 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/25775fb03e15 meth, indy: reflect pushes to hotspot-comp ! series From john.r.rose at oracle.com Thu Dec 23 14:21:30 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 23 Dec 2010 22:21:30 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-conv: replace jccb with jcc in non-product code Message-ID: <20101223222130.7CEC0476CC@hg.openjdk.java.net> Changeset: 1221fa2b2079 Author: jrose Date: 2010-12-23 14:21 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1221fa2b2079 meth-conv: replace jccb with jcc in non-product code ! meth-conv-6939861.patch From john.r.rose at oracle.com Thu Dec 23 14:21:38 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 23 Dec 2010 14:21:38 -0800 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: References: <0E1E0696-79C4-4CEC-BCA9-9CC3332E2EA9@oracle.com> <9916D13E-FB20-4E8F-A8FE-BA25CAEB17EE@oracle.com> <87AE274A-62E1-401F-B7E3-5CCD64278F5B@me.com> Message-ID: Fixed. -- John On Dec 23, 2010, at 3:36 AM, Christian Thalinger wrote: > That seems to be a problem in meth-conv-6939861. MethodHandles::verify_klass should use jcc instead of jccb. John, will you fix it or should I take care of it? From howard.lovatt at gmail.com Thu Dec 23 15:18:18 2010 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Fri, 24 Dec 2010 10:18:18 +1100 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: Hi Stephen, John Rose has just fixed a bug that was affecting me: > Fixed. -- John > > On Dec 23, 2010, at 3:36 AM, Christian Thalinger wrote: > > That seems to be a problem in meth-conv-6939861. MethodHandles::verify_klass should use jcc instead of jccb. John, will you fix it or should I take care of it? Can I impose on you at this time of good will! Any chance of a Christmas present of another Mac build incorporating this bug fix? Your efforts of building for the Mac are much appreciated. Merry Christmas, ? -- Howard. From henrik.osterdahl at oracle.com Thu Dec 23 15:18:59 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Thu, 23 Dec 2010 15:18:59 -0800 (PST) Subject: Auto Reply: RE: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: <824b796f-d398-485b-aef3-5b29820c0be0@default> Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From henrik.osterdahl at oracle.com Thu Dec 23 15:21:09 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Thu, 23 Dec 2010 15:21:09 -0800 (PST) Subject: Auto Reply: Auto Reply: RE: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From y.s.ramakrishna at oracle.com Thu Dec 23 15:21:10 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Thu, 23 Dec 2010 15:21:10 -0800 (PST) Subject: Auto Reply: Auto Reply: RE: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: <649ad0a9-470f-4eba-b3d8-5b0fbbbc465b@default> This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From henrik.osterdahl at oracle.com Thu Dec 23 15:23:15 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Thu, 23 Dec 2010 15:23:15 -0800 (PST) Subject: Auto Reply: Auto Reply: Auto Reply: RE: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization Message-ID: Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From stephen.bannasch at deanbrook.org Thu Dec 23 17:51:15 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Thu, 23 Dec 2010 20:51:15 -0500 Subject: How to run regression tests after building mlvm? Message-ID: What kinds of regression test are available for both openjdk 1.7 and mlvm and how can I run them from a shell console? Do I need jtreg: http://openjdk.java.net/jtreg/ and jtharness: https://jtharness.dev.java.net/ ? From henrik.osterdahl at oracle.com Thu Dec 23 21:00:34 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Thu, 23 Dec 2010 21:00:34 -0800 (PST) Subject: Auto Reply: How to run regression tests after building mlvm? Message-ID: Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From stephen.bannasch at deanbrook.org Thu Dec 23 21:16:13 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Fri, 24 Dec 2010 00:16:13 -0500 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: References: Message-ID: At 10:18 AM +1100 12/24/10, Howard Lovatt wrote: >Hi Stephen, > >John Rose has just fixed a bug that was affecting me: > >> Fixed. -- John >> >> On Dec 23, 2010, at 3:36 AM, Christian Thalinger wrote: >> >> That seems to be a problem in meth-conv-6939861. MethodHandles::verify_klass should use jcc instead of jccb. John, will you fix it or should I take care of it? > >Can I impose on you at this time of good will! Any chance of a >Christmas present of another Mac build incorporating this bug fix? >Your efforts of building for the Mac are much appreciated. Here's another build that includes coro from about 2 hours ago: http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-mlvm-2010_12_23.tar.gz From mroos at roos.com Sun Dec 26 11:33:17 2010 From: mroos at roos.com (Mark Roos) Date: Sun, 26 Dec 2010 11:33:17 -0800 Subject: Status of Anno Class loader with constant patches? Message-ID: We are working on a port of Smalltalk to the MLVM. For this we were thinking of using the constant patch feature of the anonymous class loader in java.dyn.anon to create constant pool entries with instances of our Smalltalk types. Is this feature expected to continue? If so in which package will it be located in the JDK7 release? If not then I assume that we have to hold these constants as static fields and create an initializer. Any other suggestions? thanks for all of the good work mark roos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101226/c7a6a4d8/attachment.html From henrik.osterdahl at oracle.com Sun Dec 26 11:34:25 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Sun, 26 Dec 2010 11:34:25 -0800 (PST) Subject: Auto Reply: Status of Anno Class loader with constant patches? Message-ID: <5d233f1f-235f-4f9f-9433-9ef598699b5a@default> Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From y.s.ramakrishna at oracle.com Sun Dec 26 11:34:25 2010 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Sun, 26 Dec 2010 11:34:25 -0800 (PST) Subject: Auto Reply: Status of Anno Class loader with constant patches? Message-ID: <4843259b-ad2a-487b-b871-18c6960ace7a@default> This is an automatic response. I am on vacation from 12/20 through 12/26, and not generally reading or responding to emai during that period. For urgent matters please contact my manager David Cox or Jon Masamitsu. From howard.lovatt at gmail.com Sun Dec 26 21:22:30 2010 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Mon, 27 Dec 2010 16:22:30 +1100 Subject: hg: mlvm/mlvm/jdk: coro: experimental coroutine thread migration and serialization In-Reply-To: References: Message-ID: Many thanks Stephen, that build fixes the problem I was seeing. On 24 December 2010 16:16, Stephen Bannasch wrote: > At 10:18 AM +1100 12/24/10, Howard Lovatt wrote: >>Hi Stephen, >> >>John Rose has just fixed a bug that was affecting me: >> >>> Fixed. ?-- John >>> >>> On Dec 23, 2010, at 3:36 AM, Christian Thalinger wrote: >>> >>> That seems to be a problem in meth-conv-6939861. ?MethodHandles::verify_klass should use jcc instead of jccb. ?John, will you fix it or should I take care of it? >> >>Can I impose on you at this time of good will! Any chance of a >>Christmas present of another Mac build incorporating this bug fix? >>Your efforts of building for the Mac are much appreciated. > > Here's another build that includes coro from about 2 hours ago: > > ?http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-mlvm-2010_12_23.tar.gz > -- ? -- Howard. From forax at univ-mlv.fr Mon Dec 27 02:53:13 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 27 Dec 2010 11:53:13 +0100 Subject: Status of Anno Class loader with constant patches? In-Reply-To: References: Message-ID: <4D187019.3080408@univ-mlv.fr> On 12/26/2010 08:33 PM, Mark Roos wrote: > We are working on a port of Smalltalk to the MLVM. For this we were > thinking of using the > constant patch feature of the anonymous class loader in java.dyn.anon > to create constant pool > entries with instances of our Smalltalk types. > > Is this feature expected to continue? If so in which package will it > be located in the JDK7 > release? > > If not then I assume that we have to hold these constants as static > fields and create an initializer. > Any other suggestions? > > thanks for all of the good work > > mark roos Hi Mark, the anonymous classloader is a Hotspot specific feature, jdk classes are in package sun.dyn.anon http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/classes/sun/dyn/anon/ Also to enable it, you need to use this flag: -XX:+AnonymousClasses This patch was not touched since a long time, so you may espect some troubles, as far as I remember, it only works with host class that is null. I really hope to that the JSR 292 expert group will standardize this API during the JDK8 timeframe. R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101227/58ec8bee/attachment.html From henrik.osterdahl at oracle.com Mon Dec 27 02:57:04 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Mon, 27 Dec 2010 02:57:04 -0800 (PST) Subject: Auto Reply: Re: Status of Anno Class loader with constant patches? Message-ID: <83fa3684-8abb-4254-8898-3708a591f528@default> Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From forax at univ-mlv.fr Mon Dec 27 03:30:21 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 27 Dec 2010 12:30:21 +0100 Subject: Bug with invokeArguments on x64 Message-ID: <4D1878CD.50708@univ-mlv.fr> Hi guys, this code crash with jdk7b123 on x64, and on x32 it raises a CCE but it should raise a WrongMethodTypeException. public class InvokeWithArgumentBug { class A { } public static void foo(A a) { } public static void main(String[] args) throws Throwable { MethodHandle mh = MethodHandles.lookup().findStatic(InvokeWithArgumentBug.class, "foo", MethodType.methodType(void.class, A.class)); mh.invokeWithArguments(2); // crash } } R?mi From headius at headius.com Mon Dec 27 09:33:05 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 27 Dec 2010 17:33:05 +0000 Subject: Status of Anno Class loader with constant patches? In-Reply-To: References: Message-ID: I am curious what you mean here...storing atypical object values (not string, int, etc) in the constant pool? Is that possible? On Sunday, December 26, 2010, Mark Roos wrote: > We are working on a port of Smalltalk to > the MLVM. ?For this we were thinking of using the > > constant patch feature of the anonymous > class loader in java.dyn.anon to create constant pool > > entries with instances of our Smalltalk > types. > > > Is this feature expected to continue? > If so in which package will it be located in the JDK7 > > release? > > > If not then I assume that we have to > hold these constants as static fields and create an initializer. > > Any other suggestions? > > > thanks for all of the good work > > > mark roos > > From henrik.osterdahl at oracle.com Mon Dec 27 09:33:42 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Mon, 27 Dec 2010 09:33:42 -0800 (PST) Subject: Auto Reply: Re: Status of Anno Class loader with constant patches? Message-ID: Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From forax at univ-mlv.fr Mon Dec 27 10:38:03 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 27 Dec 2010 19:38:03 +0100 Subject: Status of Anno Class loader with constant patches? In-Reply-To: References: Message-ID: <4D18DD0B.10807@univ-mlv.fr> On 12/27/2010 06:33 PM, Charles Oliver Nutter wrote: > I am curious what you mean here...storing atypical object values (not > string, int, etc) in the constant pool? Is that possible? The idea is to use the bytecode of an existing class as a template and to instantiate a new class from this template by replacing some constants of the template by some live objects. There is another way to do something similar, you can call invokedynamic, use the bootstrap arguments to send the primitive values composing the object value and when the BSM is called returns a ConstantCallSite with as target a method handle created by MethodHandles.constant(). The former offer a push way to store atypical constants, the later offer a pull way to store atypical constants. R?mi > On Sunday, December 26, 2010, Mark Roos wrote: >> We are working on a port of Smalltalk to >> the MLVM. For this we were thinking of using the >> >> constant patch feature of the anonymous >> class loader in java.dyn.anon to create constant pool >> >> entries with instances of our Smalltalk >> types. >> >> >> Is this feature expected to continue? >> If so in which package will it be located in the JDK7 >> >> release? >> >> >> If not then I assume that we have to >> hold these constants as static fields and create an initializer. >> >> Any other suggestions? >> >> >> thanks for all of the good work >> >> >> mark roos >> >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From henrik.osterdahl at oracle.com Mon Dec 27 10:41:51 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Mon, 27 Dec 2010 10:41:51 -0800 (PST) Subject: Auto Reply: Re: Status of Anno Class loader with constant patches? Message-ID: <4b06d903-3731-4e6f-848c-4214b861f7d3@default> Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From forax at univ-mlv.fr Tue Dec 28 02:37:45 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 28 Dec 2010 11:37:45 +0100 Subject: Crash in Compile::find_intrinsic Message-ID: <4D19BDF9.8070606@univ-mlv.fr> I've updated PHP.reboot to jdk7 b123 API. All tests pass but one: test/testfibo.phpr Step to reproduce: download phpreboot from the SVN repo: http://code.google.com/p/phpreboot/ run: bin/phpr.sh test/testfibo.phpr [forax at localhost phpreboot]$ bin/phpr.sh test/testfibo.phpr # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007faf9e935adf, pid=30902, tid=140392092649216 # # JRE version: 7.0-b123 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b04 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x386adf] Compile::find_intrinsic(ciMethod*, bool)+0x3f # # An error report file with more information is saved as: # /home/forax/java/workspace/phpreboot/hs_err_pid30902.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # bin/phpr.sh: line 36: 30902 Aborted (core dumped) java -server -ea -XX:+AnonymousClasses -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -Xbootclasspath/p:$LIB/phpreboot.jar:$LIB/tatoo-runtime.jar:$LIB/asm-all-3.2.jar:$LIB/jaxen-1.1.2.jar:$LIB/grizzly-servlet-webserver-1.9.18-k.jar:$LIB/derby.jar com.googlecode.phpreboot.Main $@ I can reproduce the crash with the 64bits and 32bits server VMs. R?mi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid30902.log Url: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101228/fc8f5881/attachment-0001.ksh From per at bothner.com Tue Dec 28 10:21:57 2010 From: per at bothner.com (Per Bothner) Date: Tue, 28 Dec 2010 10:21:57 -0800 Subject: funny characters in identifiers? Message-ID: <4D1A2AC5.2020208@bothner.com> Is there a plan/consensus for how to handle "illegal" characters in identifiers? I'm primarily interested in the bytecode level, not the Java source level. For example identifiers like '/' used for division in Scheme. It would be good to have a standard way to deal with this. One solution is to use a reversible mangling transformation. That's not necessarily ideal - for example it might be better to translate a Scheme hyphenated name 'open-input-file' to Java style 'openInputFile' for interoperability with Java, but Scheme code still needs a way to get the original name. (Kawa current solves this by translating open-input-file to an openInputFile method plus a static final Procedure-valued field 'open$Mninput$Mnfile'.) A general solution would seem to be to use an annotation. That is what we did for JavaFX. Specifically: /** * Annotation to indicate the JavaFX source name a member derives from. * Used when a the name was "mangled" to field a member name. */ @Retention(RUNTIME) @Documented @Target({METHOD, FIELD, TYPE}) public @interface SourceName { String value(); } It would be nice to standardize on an annotation type. It would also be nice to generalize to support XML (and CommonLisp) two-part names. Perhaps: public @interface SourceName { String value(); String prefix() default ""; String namespaceURI() default ""; } -- --Per Bothner per at bothner.com http://per.bothner.com/ From henrik.osterdahl at oracle.com Tue Dec 28 10:22:54 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Tue, 28 Dec 2010 10:22:54 -0800 (PST) Subject: Auto Reply: funny characters in identifiers? Message-ID: Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From mroos at roos.com Tue Dec 28 10:32:16 2010 From: mroos at roos.com (Mark Roos) Date: Tue, 28 Dec 2010 10:32:16 -0800 Subject: Status of Anno Class loader with constant patches? In-Reply-To: <4D18DD0B.10807@univ-mlv.fr> References: <4D18DD0B.10807@univ-mlv.fr> Message-ID: Thanks Remi, the extra comments really helped You also mentioned > > There is another way to do something similar, > you can call invokedynamic, use the bootstrap arguments to send > the primitive values composing the object value and when the > BSM is called returns a ConstantCallSite with as target a method handle > created by MethodHandles.constant(). At first glance this seems like adding a lot of overhead ( a method send ) as a replacement for a simple ldc bytecode. Are you thinking that hotspot will be efficient in optimizing this? I like it theoretically, as I don't have to mess with the class loader, but will the overhead be acceptable? happy new year mark roos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101228/86e44990/attachment.html From forax at univ-mlv.fr Tue Dec 28 13:53:22 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 28 Dec 2010 22:53:22 +0100 Subject: Status of Anno Class loader with constant patches? In-Reply-To: References: <4D18DD0B.10807@univ-mlv.fr> Message-ID: <4D1A5C52.5050006@univ-mlv.fr> On 12/28/2010 07:32 PM, Mark Roos wrote: > Thanks Remi, the extra comments really helped > > You also mentioned > > > > There is another way to do something similar, > > you can call invokedynamic, use the bootstrap arguments to send > > the primitive values composing the object value and when the > > BSM is called returns a ConstantCallSite with as target a method handle > > created by MethodHandles.constant(). > > At first glance this seems like adding a lot of overhead ( a method > send ) as > a replacement for a simple ldc bytecode. Are you thinking that > hotspot will be > efficient in optimizing this? We, the JSR292 EG, think that most of the VMs will be able to optimize this. > > I like it theoretically, as I don't have to mess with the class > loader, but will > the overhead be acceptable? In fact for hotspot, this kind of constant can be even more optimized than a static final field containing a non-primitive values which is not a real constant (it can be modified by reflection). > > happy new year > mark roos R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20101228/4e3b8d24/attachment.html From headius at headius.com Tue Dec 28 13:58:22 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 28 Dec 2010 15:58:22 -0600 Subject: funny characters in identifiers? In-Reply-To: <4D1A2AC5.2020208@bothner.com> References: <4D1A2AC5.2020208@bothner.com> Message-ID: On Tue, Dec 28, 2010 at 12:21 PM, Per Bothner wrote: > Is there a plan/consensus for how to handle "illegal" characters > in identifiers? ?I'm primarily interested in the bytecode level, > not the Java source level. ?For example identifiers like '/' > used for division in Scheme. ?It would be good to have a standard > way to deal with this. See John Rose's post on this here: http://blogs.sun.com/jrose/entry/symbolic_freedom_in_the_vm We have implemented it in JRuby, and it works well. The down side is that Java backtraces can be a little hard to read when there's lots of symbolic identifiers. > A general solution would seem to be to use an annotation. ?That > is what we did for JavaFX. ?Specifically: In JRuby, we have a JRubyMethod annotation we can attach to either hand-written or generated bytecode methods which has a "name" field. We generally use it only for binding methods written in Java to a Ruby name: @JRubyMethod(name = {"[]", "slice"}, reads = BACKREF, writes = BACKREF, compat = RUBY1_8) public IRubyObject op_aref(ThreadContext context, IRubyObject arg1, IRubyObject arg2) { Ruby runtime = context.getRuntime(); if (arg1 instanceof RubyRegexp) return subpat(runtime, context, (RubyRegexp)arg1, RubyNumeric.num2int(arg2)); return substr(runtime, RubyNumeric.num2int(arg1), RubyNumeric.num2int(arg2)); } - Charlie - Charlie From kirill.shirokov at oracle.com Wed Dec 29 12:09:33 2010 From: kirill.shirokov at oracle.com (Kirill Shirokov) Date: Wed, 29 Dec 2010 23:09:33 +0300 Subject: Crash in Compile::find_intrinsic In-Reply-To: References: Message-ID: <4D1B957D.4050102@oracle.com> Hi Remi, Thank you for reporting the crash. It can be tracked at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009600 Kirill From henrik.osterdahl at oracle.com Wed Dec 29 12:11:59 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Wed, 29 Dec 2010 12:11:59 -0800 (PST) Subject: Auto Reply: Re: Crash in Compile::find_intrinsic Message-ID: Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From forax at univ-mlv.fr Wed Dec 29 12:57:05 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 29 Dec 2010 21:57:05 +0100 Subject: Crash in Compile::find_intrinsic In-Reply-To: <4D1B957D.4050102@oracle.com> References: <4D1B957D.4050102@oracle.com> Message-ID: <4D1BA0A1.70506@univ-mlv.fr> On 12/29/2010 09:09 PM, Kirill Shirokov wrote: > Hi Remi, > > Thank you for reporting the crash. It can be tracked at: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009600 > > Kirill Thanks you, R?mi From kirill.shirokov at oracle.com Wed Dec 29 11:38:42 2010 From: kirill.shirokov at oracle.com (Kirill Shirokov) Date: Wed, 29 Dec 2010 22:38:42 +0300 Subject: Crash in Compile::find_intrinsic In-Reply-To: References: Message-ID: <4D1B8E42.5010504@oracle.com> Hi Remi, Thank you for reporting the crash. It can be tracked at: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7009600 Kirill From thomas.wuerthinger at gmail.com Thu Dec 30 04:40:47 2010 From: thomas.wuerthinger at gmail.com (Thomas Wuerthinger) Date: Thu, 30 Dec 2010 13:40:47 +0100 Subject: Status of Anno Class loader with constant patches? In-Reply-To: <4D1A5C52.5050006@univ-mlv.fr> References: <4D18DD0B.10807@univ-mlv.fr> <4D1A5C52.5050006@univ-mlv.fr> Message-ID: <4D1C7DCF.8040101@gmail.com> > In fact for hotspot, this kind of constant can be even more optimized > than a static final field containing a non-primitive values which is > not a real constant > (it can be modified by reflection). I don't think final fields can be modified via reflection. An IllegalAccessException with the message "field is final" is thrown at the end of Reflection::resolve_field in reflection.cpp. - thomas From henrik.osterdahl at oracle.com Thu Dec 30 04:41:28 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Thu, 30 Dec 2010 04:41:28 -0800 (PST) Subject: Auto Reply: Re: Status of Anno Class loader with constant patches? Message-ID: <0f54280c-4fe9-4db7-9fc3-6d8d024fe6b4@default> Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From forax at univ-mlv.fr Thu Dec 30 08:21:09 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 30 Dec 2010 17:21:09 +0100 Subject: Status of Anno Class loader with constant patches? In-Reply-To: <4D1C7DCF.8040101@gmail.com> References: <4D18DD0B.10807@univ-mlv.fr> <4D1A5C52.5050006@univ-mlv.fr> <4D1C7DCF.8040101@gmail.com> Message-ID: <4D1CB175.4090709@univ-mlv.fr> On 12/30/2010 01:40 PM, Thomas Wuerthinger wrote: Hi Thomas, >> In fact for hotspot, this kind of constant can be even more optimized >> than a static final field containing a non-primitive values which is >> not a real constant >> (it can be modified by reflection). > I don't think final fields can be modified via reflection. An > IllegalAccessException with the message "field is final" is thrown at > the end of Reflection::resolve_field in reflection.cpp. resolve_field is not used anymore, there is an #ifdef SUPPORT_OLD_REFLECTION before resolve_interface_call. Since 1.4, fields are created with Reflection::new_field and set() is done using sun.misc.Unsafe.putVolatile or by spinning bytecodes. (see subtypes of sun.reflect.UnsafeQualifiedFieldAccessorImpl). To sumarize: 1.2 allows to modify final fields, 1.3 forbids, 1.4+ allows using a new code. > - thomas R?mi From per at bothner.com Fri Dec 31 13:25:38 2010 From: per at bothner.com (Per Bothner) Date: Fri, 31 Dec 2010 13:25:38 -0800 Subject: funny characters in identifiers? In-Reply-To: References: <4D1A2AC5.2020208@bothner.com> Message-ID: <4D1E4A52.7090003@bothner.com> On 12/28/2010 01:58 PM, Charles Oliver Nutter wrote: > On Tue, Dec 28, 2010 at 12:21 PM, Per Bothner wrote: >> Is there a plan/consensus for how to handle "illegal" characters >> in identifiers? I'm primarily interested in the bytecode level, >> not the Java source level. For example identifiers like '/' >> used for division in Scheme. It would be good to have a standard >> way to deal with this. > > See John Rose's post on this here: > http://blogs.sun.com/jrose/entry/symbolic_freedom_in_the_vm > > We have implemented it in JRuby, and it works well. The down side is > that Java backtraces can be a little hard to read when there's lots of > symbolic identifiers. A problem with this mangling is that it isn't "safe" for class names, or at least not for class files. Using '\' in a filename is obviously problematical, especially on Windows. On Posix-based file system the funny characters are in principle allowed, but will of course be awkward to access from shells and other tools. Windows disallows the following in file names: < (less than) > (greater than) : (colon) " (double quote) / (forward slash) \ (backslash) | (vertical bar or pipe) ? (question mark) * (asterisk) http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx (And of course we have problems with-insensitive file systems.) Now of course we can use an annotation to specify the source class name in case the source class name is invalid - but then we still need to mangle the class name somehow. I think a better prefix character would be '%'. It's not reserved for Posix or Windows or JVM, while not being a valid Java character. Even better might be '~' or '!' since those are also unreserved for URIs. I will assume '~' in the following. If we want names that a "safe for filenames" or even "safe for URIs" then the problem is that there are too many unsafe characters to encode as '~' followed a safe non-alphanumeric. Which means that we need to use '`' followed by a *letter*. For example: '/' -> '~s' (mnemonic: slash) '.' -> '~d' (dot) '<' => '~l' (less) etc etc What about non-Ascii characters? I don't know enough to know if such characters might cause a problem, but don't know of any reason. They might technically be disallowed by URIs, but my impression %-mangling is handled somewhat universally and semi-transparently. -- --Per Bothner per at bothner.com http://per.bothner.com/ From cr88192 at gmail.com Fri Dec 31 14:36:57 2010 From: cr88192 at gmail.com (BGB) Date: Fri, 31 Dec 2010 15:36:57 -0700 Subject: funny characters in identifiers? In-Reply-To: <4D1E4A52.7090003@bothner.com> References: <4D1A2AC5.2020208@bothner.com> <4D1E4A52.7090003@bothner.com> Message-ID: <4D1E5B09.2000405@gmail.com> On 12/31/2010 2:25 PM, Per Bothner wrote: > On 12/28/2010 01:58 PM, Charles Oliver Nutter wrote: >> On Tue, Dec 28, 2010 at 12:21 PM, Per Bothner wrote: >>> Is there a plan/consensus for how to handle "illegal" characters >>> in identifiers? I'm primarily interested in the bytecode level, >>> not the Java source level. For example identifiers like '/' >>> used for division in Scheme. It would be good to have a standard >>> way to deal with this. >> See John Rose's post on this here: >> http://blogs.sun.com/jrose/entry/symbolic_freedom_in_the_vm >> >> We have implemented it in JRuby, and it works well. The down side is >> that Java backtraces can be a little hard to read when there's lots of >> symbolic identifiers. > A problem with this mangling is that it isn't "safe" for class names, > or at least not for class files. Using '\' in a filename is obviously > problematical, especially on Windows. On Posix-based file system the > funny characters are in principle allowed, but will of course be awkward > to access from shells and other tools. > > Windows disallows the following in file names: > < (less than) >> (greater than) > : (colon) > " (double quote) > / (forward slash) > \ (backslash) > | (vertical bar or pipe) > ? (question mark) > * (asterisk) > http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx > (And of course we have problems with-insensitive file systems.) > > Now of course we can use an annotation to specify the source class name > in case the source class name is invalid - but then we still need to > mangle the class name somehow. > > I think a better prefix character would be '%'. It's not reserved > for Posix or Windows or JVM, while not being a valid Java character. > Even better might be '~' or '!' since those are also unreserved for URIs. > I will assume '~' in the following. > > If we want names that a "safe for filenames" or even "safe for URIs" > then the problem is that there are too many unsafe characters to > encode as '~' followed a safe non-alphanumeric. Which means that > we need to use '`' followed by a *letter*. > > For example: > '/' -> '~s' (mnemonic: slash) > '.' -> '~d' (dot) > '<' => '~l' (less) > etc etc > > What about non-Ascii characters? I don't know enough to know if > such characters might cause a problem, but don't know of any reason. > They might technically be disallowed by URIs, but my impression > %-mangling is handled somewhat universally and semi-transparently. just my quick comment... in my VM, I ended up using a variation on JNI name-mangling for pretty much anything needing mangling (including filenames...). however, I did add a few additional escapes (for a few other common characters), and ended up adding a _9xx escape in addition to the _0xxxx escape. list of other escapes: '_' with '_1'; ';' with '_2'; '[' with '_3'; '(' with '_4'; ')' with '_5'; '/' with '_6'. as well, '__' was used as a string-break (mostly when encoding a list of strings as a single token). so, little says similar couldn't be used in the class filenames if needed as well... dunno if this helps for anything... From henrik.osterdahl at oracle.com Fri Dec 31 15:06:10 2010 From: henrik.osterdahl at oracle.com (henrik.osterdahl at oracle.com) Date: Fri, 31 Dec 2010 15:06:10 -0800 (PST) Subject: Auto Reply: Re: funny characters in identifiers? Message-ID: <195b94cb-18a3-4530-a7c5-b947675c13ea@default> Hello, I'm out of the office Dec 24 2010 through Jan 9 2011. Please refer to David Cox (david.cox) and Daniel K?llander (daniel.kallander). Regards, Henrik ?sterdahl From headius at headius.com Fri Dec 31 19:46:24 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 31 Dec 2010 21:46:24 -0600 Subject: funny characters in identifiers? In-Reply-To: <4D1E4A52.7090003@bothner.com> References: <4D1A2AC5.2020208@bothner.com> <4D1E4A52.7090003@bothner.com> Message-ID: On Fri, Dec 31, 2010 at 3:25 PM, Per Bothner wrote: > A problem with this mangling is that it isn't "safe" for class names, > or at least not for class files. ? Using '\' in a filename is obviously > problematical, especially on Windows. ?On Posix-based file system the > funny characters are in principle allowed, but will of course be awkward > to access from shells and other tools. I'm only using it in method names, so that didn't bother me. > Windows disallows the following in file names: > < (less than) >> (greater than) > : (colon) > " (double quote) > / (forward slash) > \ (backslash) > | (vertical bar or pipe) > ? (question mark) > * (asterisk) > http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx > (And of course we have problems with-insensitive file systems.) > > Now of course we can use an annotation to specify the source class name > in case the source class name is invalid - but then we still need to > mangle the class name somehow. > > I think a better prefix character would be '%'. ?It's not reserved > for Posix or Windows or JVM, while not being a valid Java character. > Even better might be '~' or '!' since those are also unreserved for URIs. > I will assume '~' in the following. % is used for environment variables on Windows $JAVA_HOME = %JAVA_HOME% It might be ok embedded in a filename, though...I'm not sure how twitchy it is. > If we want names that a "safe for filenames" or even "safe for URIs" > then the problem is that there are too many unsafe characters to > encode as '~' followed a safe non-alphanumeric. ?Which means that > we need to use '`' followed by a *letter*. It seems like the only safe mangling for anything seen by the filesystem is going to be alphanumeric plus a couple characters. The cross-section of characters allowable in a class name and those allowable (and not troublesome) on all filesystems is very small... Why do you need this for class *files*? - Charlie