From john.r.rose at oracle.com Sun Jul 1 01:02:36 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 01 Jul 2012 08:02:36 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: simplify linkage of user-visible MH methods Message-ID: <20120701080237.F18C547C2A@hg.openjdk.java.net> Changeset: 2ec5a5ff27c3 Author: jrose Date: 2012-07-01 01:01 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/2ec5a5ff27c3 meth: simplify linkage of user-visible MH methods ! meth-lazy-7023639.jit.patch ! meth-lazy-7023639.patch From john.r.rose at oracle.com Sun Jul 1 01:03:09 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 01 Jul 2012 08:03:09 +0000 Subject: hg: mlvm/mlvm/jdk: meth: simplify linkage of user-visible MH methods Message-ID: <20120701080309.D978147C2B@hg.openjdk.java.net> Changeset: f6f2747d37f8 Author: jrose Date: 2012-07-01 01:03 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f6f2747d37f8 meth: simplify linkage of user-visible MH methods ! meth-lazy-7023639.patch From michael.haupt at oracle.com Mon Jul 2 01:11:54 2012 From: michael.haupt at oracle.com (michael.haupt at oracle.com) Date: Mon, 02 Jul 2012 08:11:54 +0000 Subject: hg: mlvm/mlvm/jdk: meth: avoid binding of Unsafe instances and superfluous nulls in field getters/setters; provide immediate literal binding facility rudiment Message-ID: <20120702081154.9048147C38@hg.openjdk.java.net> Changeset: 9413fdf424cd Author: mhaupt Date: 2012-07-02 10:12 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/9413fdf424cd meth: avoid binding of Unsafe instances and superfluous nulls in field getters/setters; provide immediate literal binding facility rudiment ! meth-lazy-7023639.xbmh.patch From michael.haupt at oracle.com Mon Jul 2 04:27:57 2012 From: michael.haupt at oracle.com (michael.haupt at oracle.com) Date: Mon, 02 Jul 2012 11:27:57 +0000 Subject: hg: mlvm/mlvm/jdk: meth: BMH refactorings Message-ID: <20120702112758.2BF5B47C3A@hg.openjdk.java.net> Changeset: bc14db7367b6 Author: mhaupt Date: 2012-07-02 13:29 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/bc14db7367b6 meth: BMH refactorings ! meth-lazy-7023639.xbmh.patch From jlaskey at me.com Mon Jul 2 06:05:03 2012 From: jlaskey at me.com (Jim Laskey) Date: Mon, 02 Jul 2012 10:05:03 -0300 Subject: TaggedArrays (Proposal) Message-ID: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> During a week in the rarefied air of Stockholm back in May, a sleepless night got me thinking. The day after that, the thinking became a reality. I've been sitting on the code since, not sure what to do next. So..., why not start the month leading up to the JVMLS with a discussion about dynamic values. Every jLanguage developer knows that primitive boxing is the enemy. Even more so for untyped languages. We need a way to interleave primitive types with references. Tagged values (value types) for dynamic languages have been approached from a dozen different angles over the history of Java. However, no one seems to be satisfied with any of the proposals so far. Either the implementation is too limiting for the language developer or too complex to implement. Most recently, John (Rose) proposed hiding value tagging in the JVM via the Integer/Long/Float/Double.valueof methods. I saw a few issues with this proposal. First, the implementation works differently on 32 bit and 64 bit platforms (only half a solution on each). Secondly, control of the tag bits is hidden such that it doesn't give a language implementor any leeway on bit usage. Finally, it will take a long time for it to get introduced into the JVM. The implementation is complex, scattered all over the VM and will lead to a significant multiplier for testing coverage. It occurred to me on that sleepless Monday night, that the solution for most dynamic languages could be so much simpler. First, we have to look at what it is we really need. Ultimately it's about boxing. We want to avoid allocating memory whenever we need to store a primitive value in an object. Concerning ourselves with passing around tagged values in registers and storing in stack frames is all red herring. All that is needed is a mechanism for storing tagged values (or compressed values) in a no-type slot of a generic object. Thinking about it in these terms isolates all issues to a single array-like class, and thus simplifies implementation and simplifies testing. Instances of this class can be used as objects, as stack frames and even full stacks. A good percentage of a dynamic language needs are covered. So, Rickard B?ckman (also of Oracle) and I defined an API and implemented (in HotSpot) an interface called TaggedArray. Conceptional, TaggedArray is a fixed array of no-type slots (64-bit), where each slot can contain either a reference or a tagged long value (least significant bit set.) Internally, TaggedArray class's doOop method knows that it should skip any 64-bit value with the least significant bit set. How the language developer uses the other 63 bits is up to them. References are just addresses. On 32 bit machines, the address (or packed address) is stored in the high 32-bits (user has no access) So there is no interference with the tag bit. We supply four implementations of the API. 1) is a naive two parallel arrays (one Object[], one long[]) implementation for platforms not supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) that allocates each array on demand, 3) a JNI implementation (minimally needed for the interpreter) that uses the native implementation and 4) the native implementation that is recognized by both the C1/C2 compilers (effort only partially completed.) In general, the implementation choice is transparent to the user (optimal choice.) I've enclosed a JavaDoc and the roughed out source. For discussion. Fire away. Cheers, -- Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120702/7f979e3d/attachment-0003.html -------------- next part -------------- A non-text attachment was scrubbed... Name: taggedarray.zip Type: application/zip Size: 16274 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120702/7f979e3d/taggedarray-0001.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120702/7f979e3d/attachment-0004.html -------------- next part -------------- A non-text attachment was scrubbed... Name: taggedarrayjavadoc.zip Type: application/zip Size: 72468 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120702/7f979e3d/taggedarrayjavadoc-0001.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120702/7f979e3d/attachment-0005.html From forax at univ-mlv.fr Mon Jul 2 06:57:30 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 02 Jul 2012 15:57:30 +0200 Subject: TaggedArrays (Proposal) In-Reply-To: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: <4FF1A8CA.2070505@univ-mlv.fr> On 07/02/2012 03:05 PM, Jim Laskey wrote: > During a week in the rarefied air of Stockholm back in May, a > sleepless night got me thinking. The day after that, the thinking > became a reality. I've been sitting on the code since, not sure what > to do next. So..., why not start the month leading up to the JVMLS > with a discussion about dynamic values. > > Every jLanguage developer knows that primitive boxing is the enemy. > Even more so for untyped languages. We need a way to interleave > primitive types with references. > > Tagged values (value types) for dynamic languages have been approached > from a dozen different angles over the history of Java. However, no > one seems to be satisfied with any of the proposals so far. Either > the implementation is too limiting for the language developer or too > complex to implement. > > Most recently, John (Rose) proposed hiding value tagging in the JVM > via the Integer/Long/Float/Double.valueof methods. I saw a few issues > with this proposal. First, the implementation works differently on 32 > bit and 64 bit platforms (only half a solution on each). Secondly, > control of the tag bits is hidden such that it doesn't give a language > implementor any leeway on bit usage. Finally, it will take a long > time for it to get introduced into the JVM. The implementation is > complex, scattered all over the VM and will lead to a significant > multiplier for testing coverage. but it will also help Java perf. > > It occurred to me on that sleepless Monday night, that the solution > for most dynamic languages could be so much simpler. First, we have > to look at what it is we really need. Ultimately it's about boxing. > We want to avoid allocating memory whenever we need to store a > primitive value in an object. Concerning ourselves with passing > around tagged values in registers and storing in stack frames is all > red herring. All that is needed is a mechanism for storing tagged > values (or compressed values) in a no-type slot of a generic object. > Thinking about it in these terms isolates all issues to a single > array-like class, and thus simplifies implementation and simplifies > testing. Instances of this class can be used as objects, as stack > frames and even full stacks. A good percentage of a dynamic language > needs are covered. using it as a stack frames will require a pretty good escape analysis if you want same perf as the native stack or is there a trick somewhere ? But given that there is a trick to avoid boxing for local variables (see my talk at next JVM Summit), having an array like this just for storing fields is enough to pull its weight. > > So, Rickard B?ckman (also of Oracle) and I defined an API and > implemented (in HotSpot) an interface called TaggedArray. > Conceptional, TaggedArray is a fixed array of no-type slots (64-bit), > where each slot can contain either a reference or a tagged long value > (least significant bit set.) Internally, TaggedArray class's doOop > method knows that it should skip any 64-bit value with the least > significant bit set. How the language developer uses the other 63 > bits is up to them. References are just addresses. On 32 bit > machines, the address (or packed address) is stored in the high > 32-bits (user has no access) So there is no interference with the tag > bit. > > We supply four implementations of the API. 1) is a naive two parallel > arrays (one Object[], one long[]) implementation for platforms not > supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) > that allocates each array on demand, 3) a JNI implementation > (minimally needed for the interpreter) that uses the native > implementation and 4) the native implementation that is recognized by > both the C1/C2 compilers (effort only partially completed.) In > general, the implementation choice is transparent to the user (optimal > choice.) Being able to subclass it in order to add fixed field like a metaclass field, i.e a field that is always a reference, would be cool too. About the API, the two method set should be setValue()/setReference(). I think that getValue()/setValue() should return the long with the bit set because If i want to execute x + 1, I can convert it to x + 2 at compile time thus avoid the shifts at runtime. > > I've enclosed a JavaDoc and the roughed out source. For discussion. > Fire away. > > Cheers, > > -- Jim cheers, R?mi From jlaskey at me.com Mon Jul 2 07:06:24 2012 From: jlaskey at me.com (Jim Laskey) Date: Mon, 02 Jul 2012 11:06:24 -0300 Subject: TaggedArrays (Proposal) In-Reply-To: <4FF1A8CA.2070505@univ-mlv.fr> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF1A8CA.2070505@univ-mlv.fr> Message-ID: <6DCAD5A7-B4E8-47BE-B05F-995666B816ED@me.com> On 2012-07-02, at 10:57 AM, R?mi Forax wrote: > On 07/02/2012 03:05 PM, Jim Laskey wrote: >> During a week in the rarefied air of Stockholm back in May, a >> sleepless night got me thinking. The day after that, the thinking >> became a reality. I've been sitting on the code since, not sure what >> to do next. So..., why not start the month leading up to the JVMLS >> with a discussion about dynamic values. >> >> Every jLanguage developer knows that primitive boxing is the enemy. >> Even more so for untyped languages. We need a way to interleave >> primitive types with references. >> >> Tagged values (value types) for dynamic languages have been approached >> from a dozen different angles over the history of Java. However, no >> one seems to be satisfied with any of the proposals so far. Either >> the implementation is too limiting for the language developer or too >> complex to implement. >> >> Most recently, John (Rose) proposed hiding value tagging in the JVM >> via the Integer/Long/Float/Double.valueof methods. I saw a few issues >> with this proposal. First, the implementation works differently on 32 >> bit and 64 bit platforms (only half a solution on each). Secondly, >> control of the tag bits is hidden such that it doesn't give a language >> implementor any leeway on bit usage. Finally, it will take a long >> time for it to get introduced into the JVM. The implementation is >> complex, scattered all over the VM and will lead to a significant >> multiplier for testing coverage. > > but it will also help Java perf. But of course. :-) > >> >> It occurred to me on that sleepless Monday night, that the solution >> for most dynamic languages could be so much simpler. First, we have >> to look at what it is we really need. Ultimately it's about boxing. >> We want to avoid allocating memory whenever we need to store a >> primitive value in an object. Concerning ourselves with passing >> around tagged values in registers and storing in stack frames is all >> red herring. All that is needed is a mechanism for storing tagged >> values (or compressed values) in a no-type slot of a generic object. >> Thinking about it in these terms isolates all issues to a single >> array-like class, and thus simplifies implementation and simplifies >> testing. Instances of this class can be used as objects, as stack >> frames and even full stacks. A good percentage of a dynamic language >> needs are covered. > > using it as a stack frames will require a pretty good escape analysis if > you want same perf as the native stack > or is there a trick somewhere ? > But given that there is a trick to avoid boxing for local variables (see > my talk at next JVM Summit), > having an array like this just for storing fields is enough to pull its > weight. I was thinking in terms of languages that use a side stack in conjunction with the system stack. > > >> >> So, Rickard B?ckman (also of Oracle) and I defined an API and >> implemented (in HotSpot) an interface called TaggedArray. >> Conceptional, TaggedArray is a fixed array of no-type slots (64-bit), >> where each slot can contain either a reference or a tagged long value >> (least significant bit set.) Internally, TaggedArray class's doOop >> method knows that it should skip any 64-bit value with the least >> significant bit set. How the language developer uses the other 63 >> bits is up to them. References are just addresses. On 32 bit >> machines, the address (or packed address) is stored in the high >> 32-bits (user has no access) So there is no interference with the tag >> bit. >> >> We supply four implementations of the API. 1) is a naive two parallel >> arrays (one Object[], one long[]) implementation for platforms not >> supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) >> that allocates each array on demand, 3) a JNI implementation >> (minimally needed for the interpreter) that uses the native >> implementation and 4) the native implementation that is recognized by >> both the C1/C2 compilers (effort only partially completed.) In >> general, the implementation choice is transparent to the user (optimal >> choice.) > > Being able to subclass it in order to add fixed field like a metaclass > field, i.e a field that > is always a reference, would be cool too. Not so easy - the end of the tagged array object is the array area. Adding fields before that area in subclasses complicates determining the base of the array. This would also affect performance (fixed vs variable.) Reserving a slot and doing a getReference(i) on that slot would only cost you the bit test. > > About the API, the two method set should be setValue()/setReference(). Sure. > I think that getValue()/setValue() should return the long with the bit > set because > If i want to execute x + 1, I can convert it to x + 2 at compile time > thus avoid the shifts at runtime. It does return the bit. That is the point. The language developer has complete control over bits and can do what ever tricks they choose. -- Jim > >> >> I've enclosed a JavaDoc and the roughed out source. For discussion. >> Fire away. >> >> Cheers, >> >> -- Jim > > cheers, > R?mi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From ravenex at qq.com Mon Jul 2 07:11:46 2012 From: ravenex at qq.com (=?utf-8?B?cmF2ZW5leA==?=) Date: Mon, 2 Jul 2012 22:11:46 +0800 Subject: TaggedArrays (Proposal) Message-ID: Very cool stuff, Jim and Rickard! I guess people are going to start missing NaN encoded tagged value/pointers now that there's something real to play with ;-) @Remi The subclass suggestion sounds a lot like Maxine's Hybrid objects, where named fields and an untyped array is bundled into a single object. Which pretty much emulates what people like to do in C/C++, something nice to have. > I think that getValue()/setValue() should return the long with the bit set because > If i want to execute x + 1, I can convert it to x + 2 at compile time thus avoid the shifts at runtime. Even without changing the API, this kind of transformation could easily be intrinsified in the JITs, not a big worry. Cheers, Raven ------------------ Original ------------------ From: "R?mi Fora"; Date: Mon, Jul 2, 2012 09:57 PM To: "mlvm-dev"; Subject: Re: TaggedArrays (Proposal) On 07/02/2012 03:05 PM, Jim Laskey wrote: > During a week in the rarefied air of Stockholm back in May, a > sleepless night got me thinking. The day after that, the thinking > became a reality. I've been sitting on the code since, not sure what > to do next. So..., why not start the month leading up to the JVMLS > with a discussion about dynamic values. > > Every jLanguage developer knows that primitive boxing is the enemy. > Even more so for untyped languages. We need a way to interleave > primitive types with references. > > Tagged values (value types) for dynamic languages have been approached > from a dozen different angles over the history of Java. However, no > one seems to be satisfied with any of the proposals so far. Either > the implementation is too limiting for the language developer or too > complex to implement. > > Most recently, John (Rose) proposed hiding value tagging in the JVM > via the Integer/Long/Float/Double.valueof methods. I saw a few issues > with this proposal. First, the implementation works differently on 32 > bit and 64 bit platforms (only half a solution on each). Secondly, > control of the tag bits is hidden such that it doesn't give a language > implementor any leeway on bit usage. Finally, it will take a long > time for it to get introduced into the JVM. The implementation is > complex, scattered all over the VM and will lead to a significant > multiplier for testing coverage. but it will also help Java perf. > > It occurred to me on that sleepless Monday night, that the solution > for most dynamic languages could be so much simpler. First, we have > to look at what it is we really need. Ultimately it's about boxing. > We want to avoid allocating memory whenever we need to store a > primitive value in an object. Concerning ourselves with passing > around tagged values in registers and storing in stack frames is all > red herring. All that is needed is a mechanism for storing tagged > values (or compressed values) in a no-type slot of a generic object. > Thinking about it in these terms isolates all issues to a single > array-like class, and thus simplifies implementation and simplifies > testing. Instances of this class can be used as objects, as stack > frames and even full stacks. A good percentage of a dynamic language > needs are covered. using it as a stack frames will require a pretty good escape analysis if you want same perf as the native stack or is there a trick somewhere ? But given that there is a trick to avoid boxing for local variables (see my talk at next JVM Summit), having an array like this just for storing fields is enough to pull its weight. > > So, Rickard B?ckman (also of Oracle) and I defined an API and > implemented (in HotSpot) an interface called TaggedArray. > Conceptional, TaggedArray is a fixed array of no-type slots (64-bit), > where each slot can contain either a reference or a tagged long value > (least significant bit set.) Internally, TaggedArray class's doOop > method knows that it should skip any 64-bit value with the least > significant bit set. How the language developer uses the other 63 > bits is up to them. References are just addresses. On 32 bit > machines, the address (or packed address) is stored in the high > 32-bits (user has no access) So there is no interference with the tag > bit. > > We supply four implementations of the API. 1) is a naive two parallel > arrays (one Object[], one long[]) implementation for platforms not > supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) > that allocates each array on demand, 3) a JNI implementation > (minimally needed for the interpreter) that uses the native > implementation and 4) the native implementation that is recognized by > both the C1/C2 compilers (effort only partially completed.) In > general, the implementation choice is transparent to the user (optimal > choice.) Being able to subclass it in order to add fixed field like a metaclass field, i.e a field that is always a reference, would be cool too. About the API, the two method set should be setValue()/setReference(). I think that getValue()/setValue() should return the long with the bit set because If i want to execute x + 1, I can convert it to x + 2 at compile time thus avoid the shifts at runtime. > > I've enclosed a JavaDoc and the roughed out source. For discussion. > Fire away. > > Cheers, > > -- Jim cheers, R?mi _______________________________________________ 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/20120702/431061a8/attachment-0001.html From jlaskey at me.com Mon Jul 2 07:21:45 2012 From: jlaskey at me.com (Jim Laskey) Date: Mon, 02 Jul 2012 11:21:45 -0300 Subject: TaggedArrays (Proposal) In-Reply-To: References: Message-ID: We had been using NaN encodings in Nashorn but moving away from it because of 32-bit FP emulation issues. If you use a sNaN, 32-bit FP emulation converts sNaN to qNaN on load and creates a mess of things. On 2012-07-02, at 11:11 AM, ravenex wrote: > Very cool stuff, Jim and Rickard! I guess people are going to start missing NaN encoded tagged value/pointers now that there's something real to play with ;-) @Remi The subclass suggestion sounds a lot like Maxine's Hybrid objects, where named fields and an untyped array is bundled into a single object. Which pretty much emulates what people like to do in C/C++, something nice to have. > I think that getValue()/setValue() should return the long with the bit set because > If i want to execute x + 1, I can convert it to x + 2 at compile time thus avoid the shifts at runtime. Even without changing the API, this kind of transformation could easily be intrinsified in the JITs, not a big worry. Cheers, Raven ------------------ Original ------------------ From: "R?mi Fora"; Date: Mon, Jul 2, 2012 09:57 PM To: "mlvm-dev"; Subject: Re: TaggedArrays (Proposal) On 07/02/2012 03:05 PM, Jim Laskey wrote: > During a week in the rarefied air of Stockholm back in May, a > sleepless night got me thinking. The day after that, the thinking > became a reality. I've been sitting on the code since, not sure what > to do next. So..., why not start the month leading up to the JVMLS > with a discussion about dynamic values. > > Every jLanguage developer knows that primitive boxing is the enemy. > Even more so for untyped languages. We need a way to interleave > primitive types with references. > > Tagged values (value types) for dynamic languages have been approached > from a dozen different angles over the history of Java. However, no > one seems to be satisfied with any of the proposals so far. Either > the implementation is too limiting for the language developer or too > complex to implement. > > Most recently, John (Rose) proposed hiding value tagging in the JVM > via the Integer/Long/Float/Double.valueof methods. I saw a few issues > with this proposal. First, the implementation works differently on 32 > bit and 64 bit platforms (only half a solution on each). Secondly, > control of the tag bits is hidden such that it doesn't give a language > implementor any leeway on bit usage. Finally, it will take a long > time for it to get introduced into the JVM. The implementation is > complex, scattered all over the VM and will lead to a significant > multiplier for testing coverage. but it will also help Java perf. > > It occurred to me on that sleepless Monday night, that the solution > for most dynamic languages could be so much simpler. First, we have > to look at what it is we really need. Ultimately it's about boxing. > We want to avoid allocating memory whenever we need to store a > primitive value in an object. Concerning ourselves with passing > around tagged values in registers and storing in stack frames is all > red herring. All that is needed is a mechanism for storing tagged > values (or compressed values) in a no-type slot of a generic object. > Thinking about it in these terms isolates all issues to a single > array-like class, and thus simplifies implementation and simplifies > testing. Instances of this class can be used as objects, as stack > frames and even full stacks. A good percentage of a dynamic language > needs are covered. using it as a stack frames will require a pretty good escape analysis if you want same perf as the native stack or is there a trick somewhere ? But given that there is a trick to avoid boxing for local variables (see my talk at next JVM Summit), having an array like this just for storing fields is enough to pull its weight. > > So, Rickard B?ckman (also of Oracle) and I defined an API and > implemented (in HotSpot) an interface called TaggedArray. > Conceptional, TaggedArray is a fixed array of no-type slots (64-bit), > where each slot can contain either a reference or a tagged long value > (least significant bit set.) Internally, TaggedArray class's doOop > method knows that it should skip any 64-bit value with the least > significant bit set. How the language developer uses the other 63 > bits is up to them. References are just addresses. On 32 bit > machines, the address (or packed address) is stored in the high > 32-bits (user has no access) So there is no interference with the tag > bit. > > We supply four implementations of the API. 1) is a naive two parallel > arrays (one Object[], one long[]) implementation for platforms not > supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) > that allocates each array on demand, 3) a JNI implementation > (minimally needed for the interpreter) that uses the native > implementation and 4) the native implementation that is recognized by > both the C1/C2 compilers (effort only partially completed.) In > general, the implementation choice is transparent to the user (optimal > choice.) Being able to subclass it in order to add fixed field like a metaclass field, i.e a field that is always a reference, would be cool too. About the API, the two method set should be setValue()/setReference(). I think that getValue()/setValue() should return the long with the bit set because If i want to execute x + 1, I can convert it to x + 2 at compile time thus avoid the shifts at runtime. > > I've enclosed a JavaDoc and the roughed out source. For discussion. > Fire away. > > Cheers, > > -- Jim cheers, R?mi _______________________________________________ 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 ravenex at qq.com Mon Jul 2 07:34:16 2012 From: ravenex at qq.com (=?utf-8?B?cmF2ZW5leA==?=) Date: Mon, 2 Jul 2012 22:34:16 +0800 Subject: TaggedArrays (Proposal) Message-ID: So 32-bit is a pain-point for NaN encoding. I was only playing on x64 and didn't notice that. Thanks for the info! (Sorry for the messed formatting in the previous mail) - Raven ------------------ Original ------------------ From: "Jim Laskey"; Date: Mon, Jul 2, 2012 10:21 PM To: "Da Vinci Machine Project"; Subject: Re: TaggedArrays (Proposal) We had been using NaN encodings in Nashorn but moving away from it because of 32-bit FP emulation issues. If you use a sNaN, 32-bit FP emulation converts sNaN to qNaN on load and creates a mess of things. On 2012-07-02, at 11:11 AM, ravenex wrote: > Very cool stuff, Jim and Rickard! I guess people are going to start missing NaN encoded tagged value/pointers now that there's something real to play with ;-) @Remi The subclass suggestion sounds a lot like Maxine's Hybrid objects, where named fields and an untyped array is bundled into a single object. Which pretty much emulates what people like to do in C/C++, something nice to have. > I think that getValue()/setValue() should return the long with the bit set because > If i want to execute x + 1, I can convert it to x + 2 at compile time thus avoid the shifts at runtime. Even without changing the API, this kind of transformation could easily be intrinsified in the JITs, not a big worry. Cheers, Raven ------------------ Original ------------------ From: "R?mi Fora"; Date: Mon, Jul 2, 2012 09:57 PM To: "mlvm-dev"; Subject: Re: TaggedArrays (Proposal) On 07/02/2012 03:05 PM, Jim Laskey wrote: > During a week in the rarefied air of Stockholm back in May, a > sleepless night got me thinking. The day after that, the thinking > became a reality. I've been sitting on the code since, not sure what > to do next. So..., why not start the month leading up to the JVMLS > with a discussion about dynamic values. > > Every jLanguage developer knows that primitive boxing is the enemy. > Even more so for untyped languages. We need a way to interleave > primitive types with references. > > Tagged values (value types) for dynamic languages have been approached > from a dozen different angles over the history of Java. However, no > one seems to be satisfied with any of the proposals so far. Either > the implementation is too limiting for the language developer or too > complex to implement. > > Most recently, John (Rose) proposed hiding value tagging in the JVM > via the Integer/Long/Float/Double.valueof methods. I saw a few issues > with this proposal. First, the implementation works differently on 32 > bit and 64 bit platforms (only half a solution on each). Secondly, > control of the tag bits is hidden such that it doesn't give a language > implementor any leeway on bit usage. Finally, it will take a long > time for it to get introduced into the JVM. The implementation is > complex, scattered all over the VM and will lead to a significant > multiplier for testing coverage. but it will also help Java perf. > > It occurred to me on that sleepless Monday night, that the solution > for most dynamic languages could be so much simpler. First, we have > to look at what it is we really need. Ultimately it's about boxing. > We want to avoid allocating memory whenever we need to store a > primitive value in an object. Concerning ourselves with passing > around tagged values in registers and storing in stack frames is all > red herring. All that is needed is a mechanism for storing tagged > values (or compressed values) in a no-type slot of a generic object. > Thinking about it in these terms isolates all issues to a single > array-like class, and thus simplifies implementation and simplifies > testing. Instances of this class can be used as objects, as stack > frames and even full stacks. A good percentage of a dynamic language > needs are covered. using it as a stack frames will require a pretty good escape analysis if you want same perf as the native stack or is there a trick somewhere ? But given that there is a trick to avoid boxing for local variables (see my talk at next JVM Summit), having an array like this just for storing fields is enough to pull its weight. > > So, Rickard B?ckman (also of Oracle) and I defined an API and > implemented (in HotSpot) an interface called TaggedArray. > Conceptional, TaggedArray is a fixed array of no-type slots (64-bit), > where each slot can contain either a reference or a tagged long value > (least significant bit set.) Internally, TaggedArray class's doOop > method knows that it should skip any 64-bit value with the least > significant bit set. How the language developer uses the other 63 > bits is up to them. References are just addresses. On 32 bit > machines, the address (or packed address) is stored in the high > 32-bits (user has no access) So there is no interference with the tag > bit. > > We supply four implementations of the API. 1) is a naive two parallel > arrays (one Object[], one long[]) implementation for platforms not > supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) > that allocates each array on demand, 3) a JNI implementation > (minimally needed for the interpreter) that uses the native > implementation and 4) the native implementation that is recognized by > both the C1/C2 compilers (effort only partially completed.) In > general, the implementation choice is transparent to the user (optimal > choice.) Being able to subclass it in order to add fixed field like a metaclass field, i.e a field that is always a reference, would be cool too. About the API, the two method set should be setValue()/setReference(). I think that getValue()/setValue() should return the long with the bit set because If i want to execute x + 1, I can convert it to x + 2 at compile time thus avoid the shifts at runtime. > > I've enclosed a JavaDoc and the roughed out source. For discussion. > Fire away. > > Cheers, > > -- Jim cheers, R?mi _______________________________________________ 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-de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120702/3cc72c86/attachment.html From forax at univ-mlv.fr Mon Jul 2 07:44:31 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 02 Jul 2012 16:44:31 +0200 Subject: TaggedArrays (Proposal) In-Reply-To: References: Message-ID: <4FF1B3CF.4040101@univ-mlv.fr> On 07/02/2012 04:11 PM, ravenex wrote: > Very cool stuff, Jim and Rickard! > I guess people are going to start missing NaN encoded tagged > value/pointers now that there's something real to play with ;-) > > @Remi The subclass suggestion sounds a lot like Maxine's Hybrid > objects, where named fields and an untyped array is bundled into a > single object. Which pretty much emulates what people like to do in > C/C++, something nice to have. > > > I think that getValue()/setValue() should return the long with the > bit set because > > If i want to execute x + 1, I can convert it to x + 2 at compile > time thus avoid the shifts at runtime. > > Even without changing the API, this kind of transformation could > easily be intrinsified in the JITs, not a big worry. Cheers, Raven Yes, it's the Maxine hybrid object and also comes from the fact that most of the runtime have a common super type, like RubyObject in JRuby, GroovyObject in Groovy etc. which is used to provide a base class for some specialized runtime classes. R?mi From mroos at roos.com Mon Jul 2 10:23:30 2012 From: mroos at roos.com (Mark Roos) Date: Mon, 2 Jul 2012 10:23:30 -0700 Subject: TaggedArrays (Proposal) In-Reply-To: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: >From Jim It occurred to me on that sleepless Monday night, that the solution for most dynamic languages could be so much simpler. First, we have to look at what it is we really need. Ultimately it's about boxing. We want to avoid allocating memory whenever we need to store a primitive value in an object. Concerning ourselves with passing around tagged values in registers and storing in stack frames is all red herring. All that is needed is a mechanism for storing tagged values (or compressed values) in a no-type slot of a generic object. Thinking about it in these terms isolates all issues to a single array-like class, and thus simplifies implementation and simplifies testing. Instances of this class can be used as objects, as stack frames and even full stacks. A good percentage of a dynamic language needs are covered. Just having spent the last year implementing Smalltalk on the JVM the issue of boxing ( particularly for integers ) is of interest for me. While I agree with your statement that allocating memory is the big issue, I don't really understand your comment about 'when we store a primitive'. My most visible issue is in a 'for loop' like construct where I generate an index and use it to access a byte array. In this case I need to create both the index and the byte accessed. For instance scanning a million byte array requires that I create a million indexes and then another million ( assuming no cache ) one for each byte accessed. These are all then discarded. Its not clear to me how your proposal would help here. As I have thought about the boxing issue ( the Smalltalk I am using as a reference has tagged integers ) I keep thinking that any jvm solution is probably going to have some 'java' or other target driven characteristics that make it hard to use. In my case I have a java class that all of my objects are instances of. If there were a 'tagged' object type then it would have to be able to substitute as one of my instances, hold or reference the same information (like method lookups, class, shape etc ), exist on the stack or in a temp, be testable in a GWT .... Here I agree with you that making this work in the JVM is probably too difficult. So my thoughts are back to how to have a boxed primitive with no allocation overhead unless it is saved or accessed outside of a thread, in other words how to reuse the box. I can do this for some situations where I can prove the scope but I have yet to figure out a general solution. So while I can see a use for mixing references and primitives in an array it has not shown up in my work as amajor issue. Perhaps this is due to my not keeping parallel stacks? In any case hope to hear more on this at the summit regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120702/7b291f52/attachment.html From jlaskey at me.com Mon Jul 2 11:50:52 2012 From: jlaskey at me.com (Jim Laskey) Date: Mon, 02 Jul 2012 15:50:52 -0300 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: <3E2D953F-6C9A-46DE-BD79-820DC364CB68@me.com> Mark, I'll walk into the trap of offering a solution. While I'm not familiar with your implementation of SmallTalk, the array example might work like this (generic/loose java) // language stack public static TaggedArray stack = TaggedArrays.allocate(1024*1024); public static int TOS = -1; // value conversions long toValue(int i) { return ((long)i << TaggedArrays.SHIFT) | TaggedArrays.TAG; } int toInt(long v) { return (int)(v >> TaggedArrays.SHIFT) ; } // stack manipulation void pushObject(Object o) { stack.setReference(++TOS, o); } void pushInt(int i) { stack.setValue(++TOS, toValue(i)); } Object popObject() { stack.getReference(TOS--); } int popInt() { toInt(stack.getValue(TOS--)); } .... // push array on stack pushObject(new byte[10000]); // push index on stack pushInt(10); // get the array element, leaving the result on the stack invoke("getArray"); // work with the result int b = popInt(); The code for getArray might be something like (loose error handling) int i; Object a; try { i = popInt(); } catch (TaggedArrayException | IndexOutOfBoundsException ex) { // handle the fact it wasn't a value or underflow } try { a = popObject(); } catch (TaggedArrayException | IndexOutOfBoundsException ex) { // handle the fact it wasn't an object or underflow } ... if (a instanceof byte[]) { // get the byte array element long b = ((byte[])a)[i]; // push result on the stack pushInt(b); } else ... Not the best of examples, but - there are no boxed values involved here - the JVM compiler would convert setValue/setReference/getValue/getReference to simple memory access, so will perform well - the net result is very simple native code without a lot of runtime handling - note: you can choose to encrypt "values" suitable for your language needs I'll see if we can set up a TaggedArray breakout session at the summit and run thru other possibilities. Cheers, -- Jim On 2012-07-02, at 2:23 PM, Mark Roos wrote: > From Jim > > It occurred to me on that sleepless Monday night, that the solution for most dynamic languages could be so much simpler. First, we have to look at what it is we really need. Ultimately it's about boxing. We want to avoid allocating memory whenever we need to store a primitive value in an object. Concerning ourselves with passing around tagged values in registers and storing in stack frames is all red herring. All that is needed is a mechanism for storing tagged values (or compressed values) in a no-type slot of a generic object. Thinking about it in these terms isolates all issues to a single array-like class, and thus simplifies implementation and simplifies testing. Instances of this class can be used as objects, as stack frames and even full stacks. A good percentage of a dynamic language needs are covered. > > Just having spent the last year implementing Smalltalk on the JVM the issue of boxing ( particularly for integers ) is of interest for me. While I agree with > your statement that allocating memory is the big issue, I don't really understand your comment about 'when we store a primitive'. My most visible issue > is in a 'for loop' like construct where I generate an index and use it to access a byte array. In this case I need to create both the index and the byte accessed. > For instance scanning a million byte array requires that I create a million indexes and then another million ( assuming no cache ) one for each byte accessed. > These are all then discarded. Its not clear to me how your proposal would help here. > > As I have thought about the boxing issue ( the Smalltalk I am using as a reference has tagged integers ) I keep thinking that any jvm solution is probably > going to have some 'java' or other target driven characteristics that make it hard to use. In my case I have a java class that all of my objects are instances of. > If there were a 'tagged' object type then it would have to be able to substitute as one of my instances, hold or reference the same information > (like method lookups, class, shape etc ), exist on the stack or in a temp, be testable in a GWT .... > > Here I agree with you that making this work in the JVM is probably too difficult. > > So my thoughts are back to how to have a boxed primitive with no allocation overhead unless it is saved or accessed outside of a thread, in other words > how to reuse the box. I can do this for some situations where I can prove the scope but I have yet to figure out a general solution. > > So while I can see a use for mixing references and primitives in an array it has not shown up in my work as amajor issue. Perhaps this is due to my not > keeping parallel stacks? > > In any case hope to hear more on this at the summit > > regards > mark > > > > > > > > > > _______________________________________________ > 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/20120702/3395221e/attachment-0001.html From mroos at roos.com Mon Jul 2 16:14:12 2012 From: mroos at roos.com (Mark Roos) Date: Mon, 2 Jul 2012 16:14:12 -0700 Subject: TaggedArrays (Proposal) In-Reply-To: <3E2D953F-6C9A-46DE-BD79-820DC364CB68@me.com> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <3E2D953F-6C9A-46DE-BD79-820DC364CB68@me.com> Message-ID: Hi Jim, some free from thinking. My implementation does not have a parallel stack so I am using the java stack frame to hold temps and pass arguments. Even so I can see how I would use a TaggedArray. Instead of using jvm var slots I would have one slot with a Tagged Array in it to hold my method temps. When invoking a callsite I would create a TaggedArray to hold the arguments and pass that to the invoke. I could cache the frames (assuming a cheap way to null the contents of a TaggedArray) to reduce object creation. So the question is then how to handle the callsite code selection. The first GWT would have to test if the object is a reference or a tag and route. Seems like it would work. So other than extra overhead of using the arrays instead of the native stack it will probably work for me. I'll have to think some more regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120702/3e4bc89f/attachment.html From headius at headius.com Mon Jul 2 17:51:50 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 2 Jul 2012 19:51:50 -0500 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <3E2D953F-6C9A-46DE-BD79-820DC364CB68@me.com> Message-ID: A couple quick thoughts from my end. JRuby does maintain a couple parallel stacks for "out of band" data that crosses method activations, and I have explored using a large array as well for closure scopes. Currently, JRuby has a set of different-sized heap scopes for up to 4 local variables and then things failover into an array version. My experiment was to allocate one large array ahead of time and make all scopes be a single one that has an offset, size, and array reference. It would eliminate the cost of allocating scopes with N fields for N variables or allocating a scope plus an array. In practice, it did help allocation a bit, but since I still had to wrap the array in a structure to track the offsets it was a marginal improvement at best. At this point I'm still hoping for escape analysis to save me from too much allocation of boxed numerics (hard) boxed argument lists (easy, since they're usually inlinable), and closure scopes (impossible until JVMs can inline through a closure-receiving method to the closure itself). - Charlie On Mon, Jul 2, 2012 at 6:14 PM, Mark Roos wrote: > Hi Jim, ?some free from thinking. > > My implementation does not have a parallel stack so I am using the java > stack frame to hold > temps and pass arguments. ? Even so I can see how I would use a TaggedArray. > ?Instead of > using jvm var slots I would have one slot with a Tagged Array in it to hold > my method temps. > When invoking a callsite I would create a TaggedArray to hold the arguments > and pass that > to the invoke. ?I could cache the frames (assuming a cheap way to null the > contents of a > TaggedArray) to reduce object creation. > > So the question is then how to handle the callsite code selection. ?The > first GWT would > have to test if the object is a reference or a tag and route. ?Seems like it > would work. > > So other than extra overhead of using the arrays instead of the native stack > it will > probably work for me. > > I'll have to think some more > > regards > mark > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From headius at headius.com Mon Jul 2 17:56:22 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 2 Jul 2012 19:56:22 -0500 Subject: Working around NoClassDefFound Message-ID: Ok folks...last I heard from Christian the new indy backend is not going to make u6, so I'm actively seeking workarounds for the dreaded NoClassDefFoundError. I believe Remi suggested something like erasing the types in the MH tree and then re-casting them or something, but I can't find the thread. I have fixed some instances of it by making sure I generate jitted Ruby code into isolated classloaders rather than ever sharing the code across classloaders, but it's not a good general solution. I don't have an easy reproduction yet. Since it only happens when indy jits, and since I only use indy once Ruby code jits, it's a bit unpredictable. It also doesn't appear to happen with JRuby on the boot classpath...it happens only when JRuby is loaded in a child classloader. So...has anyone found a way to work around NCDFE? - Charlie From howard.lovatt at gmail.com Mon Jul 2 22:28:54 2012 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Tue, 3 Jul 2012 15:28:54 +1000 Subject: TaggedArrays (Proposal) In-Reply-To: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: I like the idea and something along these lines would be a great addition to the standard library, which I will come back to as a PS. In com.sun.misc.Unsafe there are already getLong(Object, int) and setLong(Object, int, long) methods and the same for Object. No doubt if we used getLong and setLong as they stand they would fail due to type checking if used to access references to Objects in an Object[]. However if similar methods were added that circumvented the type checking, getLongOrReference(Object, int) and setLongOrReference(Object, int, long), then you could write: private Object[] vsAndRs; ... @Override public long getValue(final int index) { checkIndex(pos); final long value = Unsafe.getLongOrReference(vsAndRs, index); if ( (value & TaggedArrays.TAG) != 0 ) { return value; } throw new TaggedArrayException("value at index =" + index + " is not tagged"); } @Override public Object getReference(final int index) { if ( isReference(index) ) { return vsAndRs[index]; } throw new TaggedArrayException("reference at index =" + index +" is tagged"); } .. Which would save half the space and still be understandable Java (i.e. not a collection of native calls). Great work, -- Howard. PS A few random thoughts for the interface, assuming that something like this makes it into the JDK then the following additions might be nice: 1. Fills that accept a lambda that receives the index as its argument (filling function as opposed to filling constant). 2. A second interface and second factory that define tagged arrays for long and double in addition to Objects, like the example code given. 3. TaggedArray32, primarily for phones etc., with the extended interface, point 2 above, for TaggedArray32 accepting Objects, ints, and floats. On a 64 bit system TaggedArray32 would be the same as TaggedArray, but for 32 bit systems it would save space. On 2 July 2012 23:05, Jim Laskey wrote: > During a week in the rarefied air of Stockholm back in May, a sleepless > night got me thinking. The day after that, the thinking became a reality. > I've been sitting on the code since, not sure what to do next. So..., why > not start the month leading up to the JVMLS with a discussion about dynamic > values. > > Every jLanguage developer knows that primitive boxing is the enemy. Even > more so for untyped languages. We need a way to interleave primitive types > with references. > > Tagged values (value types) for dynamic languages have been approached > from a dozen different angles over the history of Java. However, no one > seems to be satisfied with any of the proposals so far. Either the > implementation is too limiting for the language developer or too complex to > implement. > > Most recently, John (Rose) proposed hiding value tagging in the JVM via > the Integer/Long/Float/Double.valueof methods. I saw a few issues with > this proposal. First, the implementation works differently on 32 bit and > 64 bit platforms (only half a solution on each). Secondly, control of the > tag bits is hidden such that it doesn't give a language implementor any > leeway on bit usage. Finally, it will take a long time for it to get > introduced into the JVM. The implementation is complex, scattered all over > the VM and will lead to a significant multiplier for testing coverage. > > It occurred to me on that sleepless Monday night, that the solution for > most dynamic languages could be so much simpler. First, we have to look at > what it is we really need. Ultimately it's about boxing. We want to avoid > allocating memory whenever we need to store a primitive value in an object. > Concerning ourselves with passing around tagged values in registers and > storing in stack frames is all red herring. All that is needed is a > mechanism for storing tagged values (or compressed values) in a no-type > slot of a generic object. Thinking about it in these terms isolates all > issues to a single array-like class, and thus simplifies implementation and > simplifies testing. Instances of this class can be used as objects, as > stack frames and even full stacks. A good percentage of a dynamic language > needs are covered. > > So, Rickard B?ckman (also of Oracle) and I defined an API and implemented > (in HotSpot) an interface called TaggedArray. Conceptional, TaggedArray is > a fixed array of no-type slots (64-bit), where each slot can contain either > a reference or a tagged long value (least significant bit set.) > Internally, TaggedArray class's doOop method knows that it should skip > any 64-bit value with the least significant bit set. How the language > developer uses the other 63 bits is up to them. References are just > addresses. On 32 bit machines, the address (or packed address) is stored > in the high 32-bits (user has no access) So there is no interference with > the tag bit. > > We supply four implementations of the API. 1) is a naive two parallel > arrays (one Object[], one long[]) implementation for platforms not > supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) that > allocates each array on demand, 3) a JNI implementation (minimally needed > for the interpreter) that uses the native implementation and 4) the native > implementation that is recognized by both the C1/C2 compilers (effort only > partially completed.) In general, the implementation choice is transparent > to the user (optimal choice.) > > I've enclosed a JavaDoc and the roughed out source. For discussion. Fire > away. > > Cheers, > > -- Jim > > > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > -- -- Howard. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120703/f636593a/attachment.html From rednaxelafx at gmail.com Mon Jul 2 22:40:25 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 3 Jul 2012 13:40:25 +0800 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: On Tue, Jul 3, 2012 at 1:28 PM, Howard Lovatt wrote: > I like the idea and something along these lines would be a great addition > to the standard library, which I will come back to as a PS. > > In com.sun.misc.Unsafe there are already getLong(Object, int) and > setLong(Object, int, long) methods and the same for Object. No doubt if we > used getLong and setLong as they stand they would fail due to type checking > if used to access references to Objects in an Object[]. However if similar > methods were added that circumvented the type checking, > getLongOrReference(Object, int) and setLongOrReference(Object, int, long), > then you could write: > > private Object[] vsAndRs; > > ... > > @Override public long getValue(final int index) { > checkIndex(pos); > final long value = Unsafe.getLongOrReference(vsAndRs, index); > if ( (value & TaggedArrays.TAG) != 0 ) { > return value; > } > throw new TaggedArrayException("value at index =" + index + " is not > tagged"); > } > > @Override public Object getReference(final int index) { > if ( isReference(index) ) { > return vsAndRs[index]; > } > throw new TaggedArrayException("reference at index =" + index +" is > tagged"); > } > > .. > > Which would save half the space and still be understandable Java (i.e. not > a collection of native calls). > > It's not just about type checking at Java level, but also something deep within the VM: the need to distinguish between a plain value and a reference (pointer), which is fundamental to a exact/accurate garbage collector. Jim's idea includes modifying the doOop() function in the VM, which is exactly where HotSpot handles reference fields within an object. If you put random values into a place where HotSpot (or other JVM impls using exact GC) think it's a reference, then something bad may happen later (e.g. during GC), that the VM think it had found a corrupted reference. - Kris > Great work, > > -- Howard. > > PS A few random thoughts for the interface, assuming that something like > this makes it into the JDK then the following additions might be nice: > > 1. Fills that accept a lambda that receives the index as its argument > (filling function as opposed to filling constant). > 2. A second interface and second factory that define tagged arrays for > long and double in addition to Objects, like the example code given. > 3. TaggedArray32, primarily for phones etc., with the extended interface, > point 2 above, for TaggedArray32 accepting Objects, ints, and floats. On a > 64 bit system TaggedArray32 would be the same as TaggedArray, but for 32 > bit systems it would save space. > > > On 2 July 2012 23:05, Jim Laskey wrote: > >> During a week in the rarefied air of Stockholm back in May, a sleepless >> night got me thinking. The day after that, the thinking became a reality. >> I've been sitting on the code since, not sure what to do next. So..., why >> not start the month leading up to the JVMLS with a discussion about dynamic >> values. >> >> Every jLanguage developer knows that primitive boxing is the enemy. Even >> more so for untyped languages. We need a way to interleave primitive types >> with references. >> >> Tagged values (value types) for dynamic languages have been approached >> from a dozen different angles over the history of Java. However, no one >> seems to be satisfied with any of the proposals so far. Either the >> implementation is too limiting for the language developer or too complex to >> implement. >> >> Most recently, John (Rose) proposed hiding value tagging in the JVM via >> the Integer/Long/Float/Double.valueof methods. I saw a few issues with >> this proposal. First, the implementation works differently on 32 bit and >> 64 bit platforms (only half a solution on each). Secondly, control of the >> tag bits is hidden such that it doesn't give a language implementor any >> leeway on bit usage. Finally, it will take a long time for it to get >> introduced into the JVM. The implementation is complex, scattered all over >> the VM and will lead to a significant multiplier for testing coverage. >> >> It occurred to me on that sleepless Monday night, that the solution for >> most dynamic languages could be so much simpler. First, we have to look at >> what it is we really need. Ultimately it's about boxing. We want to avoid >> allocating memory whenever we need to store a primitive value in an object. >> Concerning ourselves with passing around tagged values in registers and >> storing in stack frames is all red herring. All that is needed is a >> mechanism for storing tagged values (or compressed values) in a no-type >> slot of a generic object. Thinking about it in these terms isolates all >> issues to a single array-like class, and thus simplifies implementation and >> simplifies testing. Instances of this class can be used as objects, as >> stack frames and even full stacks. A good percentage of a dynamic language >> needs are covered. >> >> So, Rickard B?ckman (also of Oracle) and I defined an API and implemented >> (in HotSpot) an interface called TaggedArray. Conceptional, TaggedArray is >> a fixed array of no-type slots (64-bit), where each slot can contain either >> a reference or a tagged long value (least significant bit set.) >> Internally, TaggedArray class's doOop method knows that it should skip >> any 64-bit value with the least significant bit set. How the language >> developer uses the other 63 bits is up to them. References are just >> addresses. On 32 bit machines, the address (or packed address) is stored >> in the high 32-bits (user has no access) So there is no interference with >> the tag bit. >> >> We supply four implementations of the API. 1) is a naive two parallel >> arrays (one Object[], one long[]) implementation for platforms not >> supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) that >> allocates each array on demand, 3) a JNI implementation (minimally needed >> for the interpreter) that uses the native implementation and 4) the native >> implementation that is recognized by both the C1/C2 compilers (effort only >> partially completed.) In general, the implementation choice is transparent >> to the user (optimal choice.) >> >> I've enclosed a JavaDoc and the roughed out source. For discussion. >> Fire away. >> >> Cheers, >> >> -- Jim >> >> >> >> >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> > > > -- > -- Howard. > > > _______________________________________________ > 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/20120703/3554aec7/attachment-0001.html From howard.lovatt at gmail.com Mon Jul 2 22:46:26 2012 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Tue, 3 Jul 2012 15:46:26 +1000 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: @Kris, I was assuming that the tag would be sufficient for the JVM since 'real' references would be aligned and hence naturally not tagged. But I don't know enough about the JVM and hence you could well be correct. -- Howard. On 3 July 2012 15:40, Krystal Mok wrote: > On Tue, Jul 3, 2012 at 1:28 PM, Howard Lovatt wrote: > >> I like the idea and something along these lines would be a great addition >> to the standard library, which I will come back to as a PS. >> >> In com.sun.misc.Unsafe there are already getLong(Object, int) and >> setLong(Object, int, long) methods and the same for Object. No doubt if we >> used getLong and setLong as they stand they would fail due to type checking >> if used to access references to Objects in an Object[]. However if similar >> methods were added that circumvented the type checking, >> getLongOrReference(Object, int) and setLongOrReference(Object, int, long), >> then you could write: >> >> private Object[] vsAndRs; >> >> ... >> >> @Override public long getValue(final int index) { >> checkIndex(pos); >> final long value = Unsafe.getLongOrReference(vsAndRs, index); >> if ( (value & TaggedArrays.TAG) != 0 ) { >> return value; >> } >> throw new TaggedArrayException("value at index =" + index + " is not >> tagged"); >> } >> >> @Override public Object getReference(final int index) { >> if ( isReference(index) ) { >> return vsAndRs[index]; >> } >> throw new TaggedArrayException("reference at index =" + index +" is >> tagged"); >> } >> >> .. >> >> Which would save half the space and still be understandable Java (i.e. >> not a collection of native calls). >> >> It's not just about type checking at Java level, but also something deep > within the VM: the need to distinguish between a plain value and a > reference (pointer), which is fundamental to a exact/accurate garbage > collector. > Jim's idea includes modifying the doOop() function in the VM, which is > exactly where HotSpot handles reference fields within an object. > > If you put random values into a place where HotSpot (or other JVM impls > using exact GC) think it's a reference, then something bad may happen later > (e.g. during GC), that the VM think it had found a corrupted reference. > > - Kris > > >> Great work, >> >> -- Howard. >> >> PS A few random thoughts for the interface, assuming that something like >> this makes it into the JDK then the following additions might be nice: >> >> 1. Fills that accept a lambda that receives the index as its argument >> (filling function as opposed to filling constant). >> 2. A second interface and second factory that define tagged arrays for >> long and double in addition to Objects, like the example code given. >> 3. TaggedArray32, primarily for phones etc., with the extended interface, >> point 2 above, for TaggedArray32 accepting Objects, ints, and floats. On a >> 64 bit system TaggedArray32 would be the same as TaggedArray, but for 32 >> bit systems it would save space. >> >> >> On 2 July 2012 23:05, Jim Laskey wrote: >> >>> During a week in the rarefied air of Stockholm back in May, a sleepless >>> night got me thinking. The day after that, the thinking became a reality. >>> I've been sitting on the code since, not sure what to do next. So..., why >>> not start the month leading up to the JVMLS with a discussion about dynamic >>> values. >>> >>> Every jLanguage developer knows that primitive boxing is the enemy. >>> Even more so for untyped languages. We need a way to interleave primitive >>> types with references. >>> >>> Tagged values (value types) for dynamic languages have been approached >>> from a dozen different angles over the history of Java. However, no one >>> seems to be satisfied with any of the proposals so far. Either the >>> implementation is too limiting for the language developer or too complex to >>> implement. >>> >>> Most recently, John (Rose) proposed hiding value tagging in the JVM via >>> the Integer/Long/Float/Double.valueof methods. I saw a few issues with >>> this proposal. First, the implementation works differently on 32 bit and >>> 64 bit platforms (only half a solution on each). Secondly, control of the >>> tag bits is hidden such that it doesn't give a language implementor any >>> leeway on bit usage. Finally, it will take a long time for it to get >>> introduced into the JVM. The implementation is complex, scattered all over >>> the VM and will lead to a significant multiplier for testing coverage. >>> >>> It occurred to me on that sleepless Monday night, that the solution for >>> most dynamic languages could be so much simpler. First, we have to look at >>> what it is we really need. Ultimately it's about boxing. We want to avoid >>> allocating memory whenever we need to store a primitive value in an object. >>> Concerning ourselves with passing around tagged values in registers and >>> storing in stack frames is all red herring. All that is needed is a >>> mechanism for storing tagged values (or compressed values) in a no-type >>> slot of a generic object. Thinking about it in these terms isolates all >>> issues to a single array-like class, and thus simplifies implementation and >>> simplifies testing. Instances of this class can be used as objects, as >>> stack frames and even full stacks. A good percentage of a dynamic language >>> needs are covered. >>> >>> So, Rickard B?ckman (also of Oracle) and I defined an API and >>> implemented (in HotSpot) an interface called TaggedArray. Conceptional, >>> TaggedArray is a fixed array of no-type slots (64-bit), where each slot can >>> contain either a reference or a tagged long value (least significant bit >>> set.) Internally, TaggedArray class's doOop method knows that it >>> should skip any 64-bit value with the least significant bit set. How >>> the language developer uses the other 63 bits is up to them. References >>> are just addresses. On 32 bit machines, the address (or packed address) is >>> stored in the high 32-bits (user has no access) So there is no >>> interference with the tag bit. >>> >>> We supply four implementations of the API. 1) is a naive two parallel >>> arrays (one Object[], one long[]) implementation for platforms not >>> supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) that >>> allocates each array on demand, 3) a JNI implementation (minimally needed >>> for the interpreter) that uses the native implementation and 4) the native >>> implementation that is recognized by both the C1/C2 compilers (effort only >>> partially completed.) In general, the implementation choice is transparent >>> to the user (optimal choice.) >>> >>> I've enclosed a JavaDoc and the roughed out source. For discussion. >>> Fire away. >>> >>> Cheers, >>> >>> -- Jim >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >>> >> >> >> -- >> -- 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 > > -- -- Howard. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120703/6786d96b/attachment.html From rednaxelafx at gmail.com Mon Jul 2 22:58:01 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 3 Jul 2012 13:58:01 +0800 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: @Howard Your suggestion could pretty much work if the underlying VM is using a conservative collector, where it'd actually include a set of filters to check if a value is a (or "looks like a") real reference. There are also a couple of runtimes that implements exact GC by tagging values, but most JVMs that I know of doesn't work that way. They'd expect all reference type fields to contain valid references. - Kris On Tue, Jul 3, 2012 at 1:46 PM, Howard Lovatt wrote: > @Kris, I was assuming that the tag would be sufficient for the JVM since > 'real' references would be aligned and hence naturally not tagged. But I > don't know enough about the JVM and hence you could well be correct. -- > Howard. > > > On 3 July 2012 15:40, Krystal Mok wrote: > >> On Tue, Jul 3, 2012 at 1:28 PM, Howard Lovatt wrote: >> >>> I like the idea and something along these lines would be a great >>> addition to the standard library, which I will come back to as a PS. >>> >>> In com.sun.misc.Unsafe there are already getLong(Object, int) and >>> setLong(Object, int, long) methods and the same for Object. No doubt if we >>> used getLong and setLong as they stand they would fail due to type checking >>> if used to access references to Objects in an Object[]. However if similar >>> methods were added that circumvented the type checking, >>> getLongOrReference(Object, int) and setLongOrReference(Object, int, long), >>> then you could write: >>> >>> private Object[] vsAndRs; >>> >>> ... >>> >>> @Override public long getValue(final int index) { >>> checkIndex(pos); >>> final long value = Unsafe.getLongOrReference(vsAndRs, index); >>> if ( (value & TaggedArrays.TAG) != 0 ) { >>> return value; >>> } >>> throw new TaggedArrayException("value at index =" + index + " is not >>> tagged"); >>> } >>> >>> @Override public Object getReference(final int index) { >>> if ( isReference(index) ) { >>> return vsAndRs[index]; >>> } >>> throw new TaggedArrayException("reference at index =" + index +" is >>> tagged"); >>> } >>> >>> .. >>> >>> Which would save half the space and still be understandable Java (i.e. >>> not a collection of native calls). >>> >>> It's not just about type checking at Java level, but also something deep >> within the VM: the need to distinguish between a plain value and a >> reference (pointer), which is fundamental to a exact/accurate garbage >> collector. >> Jim's idea includes modifying the doOop() function in the VM, which is >> exactly where HotSpot handles reference fields within an object. >> >> If you put random values into a place where HotSpot (or other JVM impls >> using exact GC) think it's a reference, then something bad may happen later >> (e.g. during GC), that the VM think it had found a corrupted reference. >> >> - Kris >> >> >>> Great work, >>> >>> -- Howard. >>> >>> PS A few random thoughts for the interface, assuming that something like >>> this makes it into the JDK then the following additions might be nice: >>> >>> 1. Fills that accept a lambda that receives the index as its argument >>> (filling function as opposed to filling constant). >>> 2. A second interface and second factory that define tagged arrays for >>> long and double in addition to Objects, like the example code given. >>> 3. TaggedArray32, primarily for phones etc., with the extended >>> interface, point 2 above, for TaggedArray32 accepting Objects, ints, and >>> floats. On a 64 bit system TaggedArray32 would be the same as TaggedArray, >>> but for 32 bit systems it would save space. >>> >>> >>> On 2 July 2012 23:05, Jim Laskey wrote: >>> >>>> During a week in the rarefied air of Stockholm back in May, a sleepless >>>> night got me thinking. The day after that, the thinking became a reality. >>>> I've been sitting on the code since, not sure what to do next. So..., why >>>> not start the month leading up to the JVMLS with a discussion about dynamic >>>> values. >>>> >>>> Every jLanguage developer knows that primitive boxing is the enemy. >>>> Even more so for untyped languages. We need a way to interleave primitive >>>> types with references. >>>> >>>> Tagged values (value types) for dynamic languages have been approached >>>> from a dozen different angles over the history of Java. However, no one >>>> seems to be satisfied with any of the proposals so far. Either the >>>> implementation is too limiting for the language developer or too complex to >>>> implement. >>>> >>>> Most recently, John (Rose) proposed hiding value tagging in the JVM via >>>> the Integer/Long/Float/Double.valueof methods. I saw a few issues with >>>> this proposal. First, the implementation works differently on 32 bit and >>>> 64 bit platforms (only half a solution on each). Secondly, control of the >>>> tag bits is hidden such that it doesn't give a language implementor any >>>> leeway on bit usage. Finally, it will take a long time for it to get >>>> introduced into the JVM. The implementation is complex, scattered all over >>>> the VM and will lead to a significant multiplier for testing coverage. >>>> >>>> It occurred to me on that sleepless Monday night, that the solution for >>>> most dynamic languages could be so much simpler. First, we have to look at >>>> what it is we really need. Ultimately it's about boxing. We want to avoid >>>> allocating memory whenever we need to store a primitive value in an object. >>>> Concerning ourselves with passing around tagged values in registers and >>>> storing in stack frames is all red herring. All that is needed is a >>>> mechanism for storing tagged values (or compressed values) in a no-type >>>> slot of a generic object. Thinking about it in these terms isolates all >>>> issues to a single array-like class, and thus simplifies implementation and >>>> simplifies testing. Instances of this class can be used as objects, as >>>> stack frames and even full stacks. A good percentage of a dynamic language >>>> needs are covered. >>>> >>>> So, Rickard B?ckman (also of Oracle) and I defined an API and >>>> implemented (in HotSpot) an interface called TaggedArray. Conceptional, >>>> TaggedArray is a fixed array of no-type slots (64-bit), where each slot can >>>> contain either a reference or a tagged long value (least significant bit >>>> set.) Internally, TaggedArray class's doOop method knows that it >>>> should skip any 64-bit value with the least significant bit set. How >>>> the language developer uses the other 63 bits is up to them. References >>>> are just addresses. On 32 bit machines, the address (or packed address) is >>>> stored in the high 32-bits (user has no access) So there is no >>>> interference with the tag bit. >>>> >>>> We supply four implementations of the API. 1) is a naive two parallel >>>> arrays (one Object[], one long[]) implementation for platforms not >>>> supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) that >>>> allocates each array on demand, 3) a JNI implementation (minimally needed >>>> for the interpreter) that uses the native implementation and 4) the native >>>> implementation that is recognized by both the C1/C2 compilers (effort only >>>> partially completed.) In general, the implementation choice is transparent >>>> to the user (optimal choice.) >>>> >>>> I've enclosed a JavaDoc and the roughed out source. For discussion. >>>> Fire away. >>>> >>>> Cheers, >>>> >>>> -- Jim >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>>> >>>> >>> >>> >>> -- >>> -- 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 >> >> > > > -- > -- Howard. > > > _______________________________________________ > 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/20120703/3e17a428/attachment-0001.html From john.r.rose at oracle.com Tue Jul 3 01:34:11 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 03 Jul 2012 08:34:11 +0000 Subject: hg: mlvm/mlvm/hotspot: indy: simplify indy bootstrap paths Message-ID: <20120703083412.4FF3F47C65@hg.openjdk.java.net> Changeset: 1656ab1cdcb2 Author: jrose Date: 2012-07-03 01:34 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1656ab1cdcb2 indy: simplify indy bootstrap paths ! meth-lazy-7023639.jit.patch ! meth-lazy-7023639.patch From john.r.rose at oracle.com Tue Jul 3 01:33:43 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 03 Jul 2012 08:33:43 +0000 Subject: hg: mlvm/mlvm/jdk: indy: simplify indy bootstrap paths Message-ID: <20120703083343.7F0E047C63@hg.openjdk.java.net> Changeset: 92adb37d1680 Author: jrose Date: 2012-07-03 01:33 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/92adb37d1680 indy: simplify indy bootstrap paths ! meth-lazy-7023639.patch ! meth-lazy-7023639.xbmh.patch From henri.gomez at gmail.com Tue Jul 3 06:03:12 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 3 Jul 2012 15:03:12 +0200 Subject: OSX port In-Reply-To: <30DB491D-6A1B-41D9-B57C-A629716D7E1C@oracle.com> References: <06E1B1D8-8C6A-409B-BB2C-0313A4765613@gmail.com> <30DB491D-6A1B-41D9-B57C-A629716D7E1C@oracle.com> Message-ID: Ping on this subject, ie MLVM build for OSX (but not only) in a simpler way ? 2012/5/9 John Rose : > On May 9, 2012, at 11:07 AM, Charles Oliver Nutter wrote: > >> I managed to get MLVM to build on OS X Snow Leopard with Henri's scripts. Notes: >> >> * I get a failure like this at the end of the build, but this appears >> to be after the jdk/jre have successfully built (or at least it >> appears to work fine): https://gist.github.com/749b4fe1d3b469644c11 > > Yes, I get this too. I don't know where it comes from. There is probably some configuration variable that will make it go away. Like you, I saw that the build was usable and moved on. > >> * In order to get the meth-lazy patches to apply (I'm testing the new >> indy backend) I had to remove -testable from them. I'd like a cleaner >> way. > > Christian Thalinger, Michael Haupt, and I are working hard to get these patches ready for prime time. There are several problems that show up in comprehensive testing. The worst is that TieredCompilation mode shows some failures. Until we get cleaner tests, we're keeping "-testable". > > (This raises the question of whether the keyword is misleading but I can't think of another candidate meaning for "testable". Keyword means "able to pass reasonable tests", not "able to commence testing"; the latter phrase is the meaning of "buildable".) > > You could regard the act of removing "-testable" as the equivalent of clicking through the "yes I know what I'm doing" button. You can disable the testable filter by adjusting either the series file (which is managed source code) or the guards file (which is unmanaged and private to the installation). > > ? John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From thomas.wuerthinger at oracle.com Tue Jul 3 06:49:33 2012 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Tue, 03 Jul 2012 15:49:33 +0200 Subject: TaggedArrays (Proposal) In-Reply-To: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: <4FF2F86D.1080400@oracle.com> Jim, can you also make the native part (in particular the JNI implementation) available? We'd like to experiment with it in the context of the GraalVM repository. Thx, thomas On 02.07.2012 15:05, Jim Laskey wrote: > During a week in the rarefied air of Stockholm back in May, a > sleepless night got me thinking. The day after that, the thinking > became a reality. I've been sitting on the code since, not sure what > to do next. So..., why not start the month leading up to the JVMLS > with a discussion about dynamic values. > > Every jLanguage developer knows that primitive boxing is the enemy. > Even more so for untyped languages. We need a way to interleave > primitive types with references. > > Tagged values (value types) for dynamic languages have been approached > from a dozen different angles over the history of Java. However, no > one seems to be satisfied with any of the proposals so far. Either > the implementation is too limiting for the language developer or too > complex to implement. > > Most recently, John (Rose) proposed hiding value tagging in the JVM > via the Integer/Long/Float/Double.valueof methods. I saw a few issues > with this proposal. First, the implementation works differently on 32 > bit and 64 bit platforms (only half a solution on each). Secondly, > control of the tag bits is hidden such that it doesn't give a language > implementor any leeway on bit usage. Finally, it will take a long > time for it to get introduced into the JVM. The implementation is > complex, scattered all over the VM and will lead to a significant > multiplier for testing coverage. > > It occurred to me on that sleepless Monday night, that the solution > for most dynamic languages could be so much simpler. First, we have > to look at what it is we really need. Ultimately it's about boxing. > We want to avoid allocating memory whenever we need to store a > primitive value in an object. Concerning ourselves with passing > around tagged values in registers and storing in stack frames is all > red herring. All that is needed is a mechanism for storing tagged > values (or compressed values) in a no-type slot of a generic object. > Thinking about it in these terms isolates all issues to a single > array-like class, and thus simplifies implementation and simplifies > testing. Instances of this class can be used as objects, as stack > frames and even full stacks. A good percentage of a dynamic language > needs are covered. > > So, Rickard B?ckman (also of Oracle) and I defined an API and > implemented (in HotSpot) an interface called TaggedArray. > Conceptional, TaggedArray is a fixed array of no-type slots (64-bit), > where each slot can contain either a reference or a tagged long value > (least significant bit set.) Internally, TaggedArray class's doOop > method knows that it should skip any 64-bit value with the least > significant bit set. How the language developer uses the other 63 > bits is up to them. References are just addresses. On 32 bit > machines, the address (or packed address) is stored in the high > 32-bits (user has no access) So there is no interference with the tag > bit. > > We supply four implementations of the API. 1) is a naive two parallel > arrays (one Object[], one long[]) implementation for platforms not > supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) > that allocates each array on demand, 3) a JNI implementation > (minimally needed for the interpreter) that uses the native > implementation and 4) the native implementation that is recognized by > both the C1/C2 compilers (effort only partially completed.) In > general, the implementation choice is transparent to the user (optimal > choice.) > > I've enclosed a JavaDoc and the roughed out source. For discussion. > Fire away. > > Cheers, > > -- Jim > > > > > > > > > _______________________________________________ > 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/20120703/b9936de8/attachment.html From mroos at roos.com Tue Jul 3 18:01:45 2012 From: mroos at roos.com (Mark Roos) Date: Tue, 3 Jul 2012 18:01:45 -0700 Subject: Working around NoClassDefFound In-Reply-To: References: Message-ID: >From Charlie It also doesn't appear to happen with JRuby on the boot classpath...it happens only when JRuby is loaded in a child classloader. That was my experience as well. The only way I found to avoid it was to put my code into the bootClassPath. I messed with other ideas ( but not R?mi's) but the error always eventually returned. regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120703/55aa1139/attachment.html From mroos at roos.com Tue Jul 3 18:01:46 2012 From: mroos at roos.com (Mark Roos) Date: Tue, 3 Jul 2012 18:01:46 -0700 Subject: TaggedArrays (Proposal) In-Reply-To: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: Hi Jim, You made a comment: implementation for platforms not supporting TaggedArrays (and JDK 1.7) Are you saying that a native version fo jdk1.7 is not possible, or just that you have not got around to it? regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120703/bbbf5202/attachment.html From jlaskey at me.com Tue Jul 3 18:18:57 2012 From: jlaskey at me.com (Jim Laskey) Date: Tue, 03 Jul 2012 22:18:57 -0300 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: <9D264BE5-05E5-472A-B491-2B12E97D4CCA@me.com> Actually it's built on a modified 7. Getting it into a 7 release is a community issue. I think tagged values comes under JSR-292, so some of the process is covered. Not sure what the other steps involve. And of course the API/implementation needs to be picked on a bit too. Sent from my iPhone 4 On 2012-07-03, at 10:01 PM, Mark Roos wrote: > Hi Jim, You made a comment: > > implementation for platforms not supporting TaggedArrays (and JDK 1.7) > > Are you saying that a native version fo jdk1.7 is not possible, or just that you have not got around to it? > > regards > mark > > _______________________________________________ > 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/20120703/02af30b8/attachment.html From john.r.rose at oracle.com Wed Jul 4 00:09:00 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 04 Jul 2012 07:09:00 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: clean up some names Message-ID: <20120704070901.45C4347CC5@hg.openjdk.java.net> Changeset: 27ed6912b0f6 Author: jrose Date: 2012-07-04 00:08 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/27ed6912b0f6 meth: clean up some names ! meth-lazy-7023639.patch From john.r.rose at oracle.com Wed Jul 4 00:09:15 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 04 Jul 2012 07:09:15 +0000 Subject: hg: mlvm/mlvm/jdk: meth: clean up some names Message-ID: <20120704070915.797AC47CC6@hg.openjdk.java.net> Changeset: 79934816e7a7 Author: jrose Date: 2012-07-04 00:09 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/79934816e7a7 meth: clean up some names ! meth-lazy-7023639.patch From john.r.rose at oracle.com Wed Jul 4 00:56:36 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 04 Jul 2012 07:56:36 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: clean up some names (missed qref) Message-ID: <20120704075636.EC97147CC9@hg.openjdk.java.net> Changeset: 21e1df64db36 Author: jrose Date: 2012-07-04 00:56 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/21e1df64db36 meth: clean up some names (missed qref) ! meth-lazy-7023639.jit.patch From forax at univ-mlv.fr Wed Jul 4 02:02:00 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 04 Jul 2012 11:02:00 +0200 Subject: Working around NoClassDefFound In-Reply-To: References: Message-ID: <4FF40688.1060807@univ-mlv.fr> On 07/04/2012 03:01 AM, Mark Roos wrote: > From Charlie > > It also doesn't appear to happen with JRuby on the boot > classpath...it happens only when JRuby is loaded in a child > classloader. > > That was my experience as well. The only way I found to avoid it was to > put my code into the bootClassPath. I messed with other ideas ( but not > R?mi's) but the error always eventually returned. > > regards > mark There is only one workaround to avoid the NoClassDefFound error as far as I know, the signature of all invokedynamic calls must not contain any class which is not in the bootclasspath. So either you put the runtime classes in the bootclasspath or you erase all your signature to only use primitive types and Object. cheers, R?mi From forax at univ-mlv.fr Wed Jul 4 02:03:39 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 04 Jul 2012 11:03:39 +0200 Subject: TaggedArrays (Proposal) In-Reply-To: <9D264BE5-05E5-472A-B491-2B12E97D4CCA@me.com> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <9D264BE5-05E5-472A-B491-2B12E97D4CCA@me.com> Message-ID: <4FF406EB.3050005@univ-mlv.fr> On 07/04/2012 03:18 AM, Jim Laskey wrote: > Actually it's built on a modified 7. Getting it into a 7 release is a > community issue. I think tagged values comes under JSR-292, so some of > the process is covered. Not sure what the other steps involve. And of > course the API/implementation needs to be picked on a bit too. > > Sent from my iPhone 4 Jim, is there a way to getting it as a patch in the mlvm workspace, so we can test a little bit the API/implementation. R?mi > > On 2012-07-03, at 10:01 PM, Mark Roos > wrote: > >> Hi Jim, You made a comment: >> >> implementation for platforms not supporting TaggedArrays (and JDK 1.7) >> >> Are you saying that a native version fo jdk1.7 is not possible, or >> just that you have not got around to it? >> >> regards >> mark >> >> _______________________________________________ >> 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 Wed Jul 4 02:12:42 2012 From: jlaskey at me.com (Jim Laskey) Date: Wed, 04 Jul 2012 06:12:42 -0300 Subject: TaggedArrays (Proposal) In-Reply-To: <4FF406EB.3050005@univ-mlv.fr> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <9D264BE5-05E5-472A-B491-2B12E97D4CCA@me.com> <4FF406EB.3050005@univ-mlv.fr> Message-ID: I think we can handle that. Give us a few to get at least one of the native versions working (C2/server - intel) Sent from my iPhone 4 On 2012-07-04, at 6:03 AM, R?mi Forax wrote: > On 07/04/2012 03:18 AM, Jim Laskey wrote: >> Actually it's built on a modified 7. Getting it into a 7 release is a >> community issue. I think tagged values comes under JSR-292, so some of >> the process is covered. Not sure what the other steps involve. And of >> course the API/implementation needs to be picked on a bit too. >> >> Sent from my iPhone 4 > > Jim, is there a way to getting it as a patch in the mlvm workspace, > so we can test a little bit the API/implementation. > > R?mi > >> >> On 2012-07-03, at 10:01 PM, Mark Roos > > wrote: >> >>> Hi Jim, You made a comment: >>> >>> implementation for platforms not supporting TaggedArrays (and JDK 1.7) >>> >>> Are you saying that a native version fo jdk1.7 is not possible, or >>> just that you have not got around to it? >>> >>> regards >>> mark >>> >>> _______________________________________________ >>> 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 jlaskey at me.com Wed Jul 4 02:19:23 2012 From: jlaskey at me.com (Jim Laskey) Date: Wed, 04 Jul 2012 06:19:23 -0300 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <9D264BE5-05E5-472A-B491-2B12E97D4CCA@me.com> <4FF406EB.3050005@univ-mlv.fr> Message-ID: <5A9CEC16-2A40-4B04-AB5E-774169AA8182@me.com> Note: The POC was implemented in JNI. Sent from my iPhone 4 On 2012-07-04, at 6:12 AM, Jim Laskey wrote: > I think we can handle that. Give us a few to get at least one of the native versions working (C2/server - intel) > > Sent from my iPhone 4 > > On 2012-07-04, at 6:03 AM, R?mi Forax wrote: > >> On 07/04/2012 03:18 AM, Jim Laskey wrote: >>> Actually it's built on a modified 7. Getting it into a 7 release is a >>> community issue. I think tagged values comes under JSR-292, so some of >>> the process is covered. Not sure what the other steps involve. And of >>> course the API/implementation needs to be picked on a bit too. >>> >>> Sent from my iPhone 4 >> >> Jim, is there a way to getting it as a patch in the mlvm workspace, >> so we can test a little bit the API/implementation. >> >> R?mi >> >>> >>> On 2012-07-03, at 10:01 PM, Mark Roos >> > wrote: >>> >>>> Hi Jim, You made a comment: >>>> >>>> implementation for platforms not supporting TaggedArrays (and JDK 1.7) >>>> >>>> Are you saying that a native version fo jdk1.7 is not possible, or >>>> just that you have not got around to it? >>>> >>>> regards >>>> mark >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From headius at headius.com Wed Jul 4 15:44:43 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 4 Jul 2012 17:44:43 -0500 Subject: Working around NoClassDefFound In-Reply-To: <4FF40688.1060807@univ-mlv.fr> References: <4FF40688.1060807@univ-mlv.fr> Message-ID: Thanks Remi, that makes sense. My call paths don't have too many types (4 or 5 maybe) so this might be worth exploring. I assume this includes any handles to cast back to those types. Hmm...an idea is forming. I will try to play with this later this week. - Charlie (mobile) On Jul 4, 2012 3:59 AM, "R?mi Forax" wrote: > On 07/04/2012 03:01 AM, Mark Roos wrote: > > From Charlie > > > > It also doesn't appear to happen with JRuby on the boot > > classpath...it happens only when JRuby is loaded in a child > > classloader. > > > > That was my experience as well. The only way I found to avoid it was to > > put my code into the bootClassPath. I messed with other ideas ( but not > > R?mi's) but the error always eventually returned. > > > > regards > > mark > > There is only one workaround to avoid the NoClassDefFound error as far > as I know, > the signature of all invokedynamic calls must not contain any class > which is not in the bootclasspath. > So either you put the runtime classes in the bootclasspath or you erase > all your signature to only use > primitive types and Object. > > cheers, > R?mi > > _______________________________________________ > 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/20120704/a3cfdded/attachment.html From john.r.rose at oracle.com Wed Jul 4 15:48:04 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 04 Jul 2012 22:48:04 +0000 Subject: hg: mlvm/mlvm/jdk: meth: more precise DMH receiver types Message-ID: <20120704224804.E266647CDD@hg.openjdk.java.net> Changeset: 1d7b2c68670f Author: jrose Date: 2012-07-04 15:47 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/1d7b2c68670f meth: more precise DMH receiver types ! meth-lazy-7023639.patch ! meth-lazy-7023639.xbmh.patch From john.r.rose at oracle.com Wed Jul 4 16:10:04 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 04 Jul 2012 23:10:04 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: more precise DMH receiver types (partial) Message-ID: <20120704231005.2601947CE6@hg.openjdk.java.net> Changeset: b43840515862 Author: jrose Date: 2012-07-04 16:10 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b43840515862 meth: more precise DMH receiver types (partial) ! meth-lazy-7023639.patch From henri.gomez at gmail.com Wed Jul 4 23:46:11 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 5 Jul 2012 08:46:11 +0200 Subject: OSX port In-Reply-To: References: <06E1B1D8-8C6A-409B-BB2C-0313A4765613@gmail.com> <30DB491D-6A1B-41D9-B57C-A629716D7E1C@oracle.com> Message-ID: I tried my old build system for MLVM to produce a new package for OSX but it fail : (cd /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-mlvm/workspace/sources/build/macosx-x86_64/bin/.. && /usr/bin/tar cf - \ `/usr/bin/find bin \( -type f -o -type l \) -print `) | \ (cd /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-mlvm/workspace/sources/build/macosx-x86_64/j2sdk-image && /usr/bin/tar xf -) /usr/bin/touch /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-mlvm/workspace/sources/build/macosx-x86_64/classes/META-INF/services/com.sun.tools.internal.xjc.Plugin cd /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-mlvm/workspace/sources/build/macosx-x86_64/classes && \ /Library/Java/JavaVirtualMachines/1.7.0u4.jdk/Contents/Home/bin/jar c0f /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-mlvm/workspace/sources/build/macosx-x86_64/lib/tools.jar \ META-INF/services/com.sun.jdi.connect.Connector META-INF/services/com.sun.jdi.connect.spi.TransportService sun/tools/asm sun/tools/jar sun/tools/java sun/tools/javac sun/tools/jcmd sun/tools/jps sun/tools/jstat sun/tools/jstatd sun/tools/native2ascii sun/tools/serialver sun/tools/tree sun/tools/util sun/security/tools/JarBASE64Encoder.class sun/security/tools/JarSigner.class sun/security/tools/JarSignerParameters.class sun/security/tools/JarSignerResources.class sun/security/tools/JarSignerResources_ja.class sun/security/tools/JarSignerResources_zh_CN.class sun/security/tools/SignatureFile\$Block.class sun/security/tools/SignatureFile.class sun/security/tools/TimestampedSigner.class sun/rmi/rmic sun/applet sun/jvmstat com/sun/javadoc com/sun/jdi com/sun/jarsigner com/sun/source com/sun/tools/classfile com/sun/tools/doclets com/sun/tools/example/debug/expr com/sun/tools/example/debug/tty com/sun/tools/extcheck com/sun/tools/hat com/sun/tools/javac com/sun/tools/javadoc com/sun/tools/javah com/sun/tools/javap com/sun/tools/corba com/sun/tools/internal/xjc com/sun/tools/internal/ws META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin META-INF/services/com.sun.tools.internal.xjc.Plugin com/sun/istack/internal/tools com/sun/tools/internal/jxc/ap com/sun/tools/internal/ws/wscompile/plugin/at_generated com/sun/codemodel com/sun/tools/internal/jxc com/sun/xml/internal/rngom com/sun/xml/internal/xsom org/relaxng/datatype com/sun/xml/internal/dtdparser com/sun/tools/jdi com/sun/tools/script/shell META-INF/services/com.sun.tools.attach.spi.AttachProvider com/sun/tools/attach sun/tools/attach sun/tools/jstack sun/tools/jinfo sun/tools/jmap -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Djava.awt.headless=true -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin : fichier ou r?pertoire introuvable com/sun/tools/internal/jxc/ap : fichier ou r?pertoire introuvable com/sun/tools/internal/ws/wscompile/plugin/at_generated : fichier ou r?pertoire introuvable make[2]: *** [initial-image-jdk] Error 1 make[1]: *** [jdk-build] Error 2 make: *** [build_product_image] Error 2 What's current build process to be used ? Thanks 2012/7/3 Henri Gomez : > Ping on this subject, ie MLVM build for OSX (but not only) in a simpler way ? > > 2012/5/9 John Rose : >> On May 9, 2012, at 11:07 AM, Charles Oliver Nutter wrote: >> >>> I managed to get MLVM to build on OS X Snow Leopard with Henri's scripts. Notes: >>> >>> * I get a failure like this at the end of the build, but this appears >>> to be after the jdk/jre have successfully built (or at least it >>> appears to work fine): https://gist.github.com/749b4fe1d3b469644c11 >> >> Yes, I get this too. I don't know where it comes from. There is probably some configuration variable that will make it go away. Like you, I saw that the build was usable and moved on. >> >>> * In order to get the meth-lazy patches to apply (I'm testing the new >>> indy backend) I had to remove -testable from them. I'd like a cleaner >>> way. >> >> Christian Thalinger, Michael Haupt, and I are working hard to get these patches ready for prime time. There are several problems that show up in comprehensive testing. The worst is that TieredCompilation mode shows some failures. Until we get cleaner tests, we're keeping "-testable". >> >> (This raises the question of whether the keyword is misleading but I can't think of another candidate meaning for "testable". Keyword means "able to pass reasonable tests", not "able to commence testing"; the latter phrase is the meaning of "buildable".) >> >> You could regard the act of removing "-testable" as the equivalent of clicking through the "yes I know what I'm doing" button. You can disable the testable filter by adjusting either the series file (which is managed source code) or the guards file (which is unmanaged and private to the installation). >> >> ? John >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From mroos at roos.com Thu Jul 5 13:26:05 2012 From: mroos at roos.com (Mark Roos) Date: Thu, 5 Jul 2012 13:26:05 -0700 Subject: TaggedArrays (Proposal) In-Reply-To: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: Hi Jim I was wondering if you could post the use case that led you develop the TaggedArray? I looked over our Smalltalk app and I could not see an obvious pattern where mixing primitives and references in a collection is common. On a similar note I was curious how you are avoiding the integer allocation when using a 'for' like pattern to index over an array. That is a real performance hit for me so I am looking for a good solution thanks mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120705/b3565e4a/attachment.html From jlaskey at me.com Thu Jul 5 13:42:06 2012 From: jlaskey at me.com (Jim Laskey) Date: Thu, 05 Jul 2012 17:42:06 -0300 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: Fairly common patterns like var p = { fontsize: 15, lineheight: 22, color: 0x000, fontfamily: "Georgia, FreeSerif, Times, serif" }; p.color = "white"; We need flexible slots without allocating 2x memory. For "for like" constructs we typically use static analysis to reduce to integer. With TaggedArray slots for frames we could use integer dynamically. Cheers, -- Jim On 2012-07-05, at 5:26 PM, Mark Roos wrote: > Hi Jim > > I was wondering if you could post the use case that led you develop the TaggedArray? > I looked over our Smalltalk app and I could not see an obvious pattern where mixing > primitives and references in a collection is common. > > On a similar note I was curious how you are avoiding the integer allocation when using > a 'for' like pattern to index over an array. That is a real performance hit for me so I > am looking for a good solution > > thanks > mark_______________________________________________ > 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/20120705/74b19069/attachment.html From forax at univ-mlv.fr Thu Jul 5 17:26:32 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 06 Jul 2012 02:26:32 +0200 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: <4FF630B8.8030400@univ-mlv.fr> On 07/05/2012 10:42 PM, Jim Laskey wrote: > Fairly common patterns like > > var p = { > fontsize: 15, > lineheight: 22, > color: 0x000, > fontfamily: "Georgia, FreeSerif, Times, serif" > }; > > p.color = "white"; > > We need flexible slots without allocating 2x memory. > > For "for like" constructs we typically use static analysis to reduce > to integer. Not having such kind of analysis is almost a crime. Jim, do you have a paper explaining the static analysis you use, I have some trouble to keep mine linear. > With TaggedArray slots for frames we could use integer dynamically. yes, but performance will be awful (ok, better than using boxing but 2x or 3x slower than C or Java) if you don't have any kind of type propagation. > > Cheers, > > -- Jim cheers, R?mi From jlaskey at me.com Thu Jul 5 17:59:02 2012 From: jlaskey at me.com (Jim Laskey) Date: Thu, 05 Jul 2012 21:59:02 -0300 Subject: TaggedArrays (Proposal) In-Reply-To: <4FF630B8.8030400@univ-mlv.fr> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> Message-ID: <61AF2F2A-0930-406A-901F-A4851975A955@me.com> On 2012-07-05, at 9:26 PM, R?mi Forax wrote: > On 07/05/2012 10:42 PM, Jim Laskey wrote: >> Fairly common patterns like >> >> var p = { >> fontsize: 15, >> lineheight: 22, >> color: 0x000, >> fontfamily: "Georgia, FreeSerif, Times, serif" >> }; >> >> p.color = "white"; >> >> We need flexible slots without allocating 2x memory. >> >> For "for like" constructs we typically use static analysis to reduce >> to integer. > > Not having such kind of analysis is almost a crime. > > Jim, do you have a paper explaining the static analysis you use, > I have some trouble to keep mine linear. > Marcus Lagergren will be doing a talk at JavaOne on type specific optimizations that we use. >> With TaggedArray slots for frames we could use integer dynamically. > > yes, but performance will be awful (ok, better than using boxing but 2x > or 3x slower > than C or Java) if you don't have any kind of type propagation. We're seeing 2x using C2, but the benefit is that if you have to roll over into another type (ex. box) you can use the same slot. One subtlety I should point out, the plan is to have the copy method optimized to inline small copies, so that constant length copies of 1-4 (or so) will be native memory to memory moves. This means you can move values, object/frame/stack to object/frame/stack without any type checking (1-1 with C/Java.) > >> >> Cheers, >> >> -- Jim > > cheers, > R?mi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From mroos at roos.com Thu Jul 5 19:41:26 2012 From: mroos at roos.com (Mark Roos) Date: Thu, 5 Jul 2012 19:41:26 -0700 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> Message-ID: I see, it looks like you are using them to hold instance vars of objects. I was looking for large arrays/collections. I have looked at this before in our app but the number of integers used like this did not seem to warrant much concern ( Double Vectors and byte[] are the dominant memory users). thanks mark From: Jim Laskey To: Da Vinci Machine Project Date: 07/05/2012 01:51 PM Subject: Re: TaggedArrays (Proposal) Sent by: mlvm-dev-bounces at openjdk.java.net Fairly common patterns like var p = { fontsize: 15, lineheight: 22, color: 0x000, fontfamily: "Georgia, FreeSerif, Times, serif" }; p.color = "white"; We need flexible slots without allocating 2x memory. For "for like" constructs we typically use static analysis to reduce to integer. With TaggedArray slots for frames we could use integer dynamically. Cheers, -- Jim On 2012-07-05, at 5:26 PM, Mark Roos wrote: Hi Ji! m I was wondering if you could post the use case that led you develop the TaggedArray? I looked over our Smalltalk app and I could not see an obvious pattern where mixing primitives and references in a collection is common. On a similar note I was curious how you are avoiding the integer allocation when using a 'for' like pattern to index over an array. That is a real performance hit for me so I am looking for a good solution thanks mark_______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120705/85fd5ccc/attachment.html From mroos at roos.com Fri Jul 6 11:48:53 2012 From: mroos at roos.com (Mark Roos) Date: Fri, 6 Jul 2012 11:48:53 -0700 Subject: TaggedArrays (Proposal) In-Reply-To: <4FF630B8.8030400@univ-mlv.fr> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> Message-ID: >From R?mi on static analysis for loops Not having such kind of analysis is almost a crime. For a language like Smalltalk I was thinking that having such an analysis would be the work of the gods. With user overridable methods, reflection and run time code creation I have only found a few places where I could do such an static analysis. And those are fragile. So do you have a good paper that would apply? I have looked at many from the 80s/90s and have yet to find a general approach for a Smalltalk style language. I am thinking of adding a mutable flag to integers so I can share a body but 'lazy' freeze to a real integer but it seems like I'll be adding lots of checks just to fix what could be a small problem over an entire application. I also have a thought to allocate a few primitive slots in each stack frame to pass real primitives but again I have to test everywhere for which slot is valid. The best thought may be to add patterns to the language to avoid the use of visible integers as indexes ( e.g. instead of '1 to:3 do:[aBlock over a collection]' do 'aCollection from:1 to:3 do:[ aBlock on each indexed item]') Now I can do the static analysis. As they say 'If it hurts don't do it' regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120706/973319db/attachment.html From forax at univ-mlv.fr Fri Jul 6 14:20:53 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 06 Jul 2012 23:20:53 +0200 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> Message-ID: <4FF756B5.4040003@univ-mlv.fr> On 07/06/2012 08:48 PM, Mark Roos wrote: > From R?mi on static analysis for loops > > Not having such kind of analysis is almost a crime. > > For a language like Smalltalk I was thinking that having such an analysis > would be the work of the gods. > > With user overridable methods, reflection and run time code creation I > have only found a few > places where I could do such an static analysis. And those are fragile. > > So do you have a good paper that would apply? I have looked at many > from the 80s/90s and > have yet to find a general approach for a Smalltalk style language. > > I am thinking of adding a mutable flag to integers so I can share a > body but 'lazy' freeze to > a real integer but it seems like I'll be adding lots of checks just to > fix what could be a small problem > over an entire application. yes, i don't think it's a good idea too because it's too late, you want to avoid boxing not try to share boxes. > > I also have a thought to allocate a few primitive slots in each stack > frame to pass real primitives > but again I have to test everywhere for which slot is valid. First the idea is to use an analysis but not to answer to the question, "is this variable is an integer or not" but to answer to the question "is this variable may be an integer or not". Once the analysis done, you know how many supplementary slots you need. And now the trick, there is a nice way (several in fact) to explain to the JIT that even if the bytecode contains tests, if the variable contains effectively an int, it's a good idea to remove them. > > The best thought may be to add patterns to the language to avoid the > use of visible integers > as indexes ( e.g. instead of '1 to:3 do:[aBlock over a collection]' > do 'aCollection from:1 to:3 do:[ aBlock on each indexed item]') > Now I can do the static analysis. As they say 'If it hurts don't do it' > regards > mark cheers, R?mi From mark.reinhold at oracle.com Fri Jul 6 15:16:24 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 6 Jul 2012 15:16:24 -0700 (PDT) Subject: JEP 160: Lambda-Form Representation for Method Handles Message-ID: <20120706221624.9C79AD3B@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/160 - Mark From christian.thalinger at oracle.com Fri Jul 6 17:07:08 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 07 Jul 2012 00:07:08 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: compiler snapshot Message-ID: <20120707000710.2F8B147E06@hg.openjdk.java.net> Changeset: 649f4375edec Author: twisti Date: 2012-07-06 17:06 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/649f4375edec meth-lazy: compiler snapshot ! meth-lazy-7023639.jit.patch From christian.thalinger at oracle.com Fri Jul 6 17:07:24 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 07 Jul 2012 00:07:24 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: compiler snapshot Message-ID: <20120707000725.500C247E09@hg.openjdk.java.net> Changeset: fc8827d8a966 Author: twisti Date: 2012-07-06 17:06 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/fc8827d8a966 meth-lazy: compiler snapshot ! meth-lazy-7023639.patch From mroos at roos.com Fri Jul 6 19:54:26 2012 From: mroos at roos.com (Mark Roos) Date: Fri, 6 Jul 2012 19:54:26 -0700 Subject: TaggedArrays (Proposal) In-Reply-To: <4FF756B5.4040003@univ-mlv.fr> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> <4FF756B5.4040003@univ-mlv.fr> Message-ID: Hi R?mi, you mention And now the trick, there is a nice way (several in fact) to explain to the JIT that even if the bytecode contains tests, if the variable contains effectively an int, it's a good idea to remove them. Ok, in Smalltalk there are some methods which are usually integer ops so its easy to determine vars that are likely integer. I have slots in the stack reserved for just this idea. So if I have a pair of slots A and B where A would be the integer from and B the reference. Would I test B to be null and if so do an integer op on A? So plese point me at the bytecode tricks that make the test go away. regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120706/4ac98fa8/attachment.html From stephen.bannasch at deanbrook.org Fri Jul 6 22:06:55 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sat, 7 Jul 2012 01:06:55 -0400 Subject: build failed: no such file: com.sun.tools.internal.ws.wscompile.Plugin Message-ID: Haven't built mlvm in a while and when I tried today the build failed while trying to create tools.jar in this directory: build/macosx-x86_64/j2sdk-image/lib with this error: META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin : no such file or directory see: https://gist.github.com/3064208 1.7.0_06 builds fine 1.8.0 from http://hg.openjdk.java.net/jdk8/tl also builds fine From forax at univ-mlv.fr Sat Jul 7 01:56:51 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 07 Jul 2012 10:56:51 +0200 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> <4FF756B5.4040003@univ-mlv.fr> Message-ID: <4FF7F9D3.6070901@univ-mlv.fr> On 07/07/2012 04:54 AM, Mark Roos wrote: > Hi R?mi, you mention > And now the trick, there is a nice way (several in fact) to explain to > the JIT > that even if the bytecode contains tests, if the variable contains > effectively an int, > it's a good idea to remove them. > > Ok, in Smalltalk there are some methods which are usually integer ops > so its easy to determine vars that are likely integer. I have slots in > the stack reserved for just this idea. > > So if I have a pair of slots A and B where A would be the integer from > and B the reference. > Would I test B to be null and if so do an integer op on A? yes, that the basic idea. > > So plese point me at the bytecode tricks that make the test go away. It's not a bytecode trick, it's a JIT trick. The VM profiles jump instruction like 'if' to know which branch is taken, and doesn't generate code but a deoptimization code if a branch is never taken. So the generator of a backend will generate a code like this for a + 1: int r1 = ... Object o1 = ... if (o1 == null) { r2 = r1 + 1 o2 = null } else { r2 = 0 o2 = invokedynamic + o1, 1 } if (o2 == null) { // next instruction ... } else { ... ... and because o1 is never null, the JIT will generate jne a_deoptimization_code inc r2 also because the JIT propagates null value aggressively, the jump can also disappear because there is perhaps already another check before, by example, the check o2 == null will be removed here. So the idea is to consider that if a variable can store an int, you should use two variables in the bytecode, so result of an operation will be spilled into two variables instead of using the stack. I call this idea, split-path and this is really effective, the main drawback is that the generated bytecode size is big compared to the code of the generated assembler so the JIT may decide to not inline something that it should. You have also to figure out how to get two return values from a method call, but exceptions are your best friend here. > > regards > mark rgds, R?mi From john.r.rose at oracle.com Sat Jul 7 05:52:06 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 07 Jul 2012 12:52:06 +0000 Subject: hg: mlvm/mlvm/jdk: meth: work through cleanups; fix bugs Message-ID: <20120707125207.B21E947E25@hg.openjdk.java.net> Changeset: 05e2216c0b10 Author: jrose Date: 2012-07-07 05:51 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/05e2216c0b10 meth: work through cleanups; fix bugs ! meth-lazy-7023639.patch ! meth-lazy-7023639.xbmh.patch From john.r.rose at oracle.com Sat Jul 7 05:52:31 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 07 Jul 2012 12:52:31 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: coordinate ports (x86_{32,64}, sparc); work through cleanups; fix bugs Message-ID: <20120707125232.6F03047E28@hg.openjdk.java.net> Changeset: 4799b4508e19 Author: jrose Date: 2012-07-07 05:52 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/4799b4508e19 meth: coordinate ports (x86_{32,64}, sparc); work through cleanups; fix bugs ! meth-lazy-7023639.jit.patch ! meth-lazy-7023639.patch From dain at iq80.com Sat Jul 7 10:02:57 2012 From: dain at iq80.com (Dain Sundstrom) Date: Sat, 7 Jul 2012 10:02:57 -0700 Subject: TaggedArrays (Proposal) In-Reply-To: <4FF7F9D3.6070901@univ-mlv.fr> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> <4FF756B5.4040003@univ-mlv.fr> <4FF7F9D3.6070901@univ-mlv.fr> Message-ID: On Jul 7, 2012, at 1:56 AM, R?mi Forax wrote: > You have also to figure out how to get two return values from a method call, > but exceptions are your best friend here. Can you give an example of what you mean here? Also, from all the presentations I've seen on the JVM, exceptions are very expensive to throw and catch, so I would expect this to be way slower then say returning the multiple values using a generated results class. -dain From forax at univ-mlv.fr Sat Jul 7 11:45:11 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 07 Jul 2012 20:45:11 +0200 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> <4FF756B5.4040003@univ-mlv.fr> <4FF7F9D3.6070901@univ-mlv.fr> Message-ID: <4FF883B7.7090405@univ-mlv.fr> On 07/07/2012 07:02 PM, Dain Sundstrom wrote: > On Jul 7, 2012, at 1:56 AM, R?mi Forax wrote: > >> You have also to figure out how to get two return values from a method call, >> but exceptions are your best friend here. > Can you give an example of what you mean here? Also, from all the presentations I've seen on the JVM, exceptions are very expensive to throw and catch, so I would expect this to be way slower then say returning the multiple values using a generated results class. Exception are not expensive if you throw them and just catch them (and don't use them) in the same inlining horizon, so you can use them to implement non Java control flow without thinking too much. Anyway, the idea here is to use exception as an exceptional mechanism by example when something that should be an int is not. In that case, throwing an exception is not a big deal because the VM will have to deopt which usual have a bigger impact on the run time. > > -dain R?mi From vitalyd at gmail.com Sat Jul 7 11:48:47 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Sat, 7 Jul 2012 14:48:47 -0400 Subject: TaggedArrays (Proposal) In-Reply-To: <4FF883B7.7090405@univ-mlv.fr> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> <4FF756B5.4040003@univ-mlv.fr> <4FF7F9D3.6070901@univ-mlv.fr> <4FF883B7.7090405@univ-mlv.fr> Message-ID: Here's a blog post from John Rose explaining that exception throwing compiles to a goto in cases like this: https://blogs.oracle.com/jrose/entry/longjumps_considered_inexpensive Sent from my phone On Jul 7, 2012 2:43 PM, "R?mi Forax" wrote: > On 07/07/2012 07:02 PM, Dain Sundstrom wrote: > > On Jul 7, 2012, at 1:56 AM, R?mi Forax wrote: > > > >> You have also to figure out how to get two return values from a method > call, > >> but exceptions are your best friend here. > > Can you give an example of what you mean here? Also, from all the > presentations I've seen on the JVM, exceptions are very expensive to throw > and catch, so I would expect this to be way slower then say returning the > multiple values using a generated results class. > > Exception are not expensive if you throw them and just catch them (and > don't use them) in the same inlining horizon, > so you can use them to implement non Java control flow without thinking > too much. > > Anyway, the idea here is to use exception as an exceptional mechanism by > example when > something that should be an int is not. In that case, throwing an > exception is not a big deal > because the VM will have to deopt which usual have a bigger impact on > the run time. > > > > > -dain > > R?mi > > _______________________________________________ > 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/20120707/8c796534/attachment.html From dain at iq80.com Sat Jul 7 12:08:15 2012 From: dain at iq80.com (Dain Sundstrom) Date: Sat, 7 Jul 2012 12:08:15 -0700 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> <4FF756B5.4040003@univ-mlv.fr> <4FF7F9D3.6070901@univ-mlv.fr> <4FF883B7.7090405@univ-mlv.fr> Message-ID: <0DFC2ADC-205E-4F19-B84B-AAF9042185D1@iq80.com> Wow. That dramatically changes my mental model of exceptions in the JVM. This is going to dramatically simplify some of my code. thanks -dain On Jul 7, 2012, at 11:48 AM, Vitaly Davidovich wrote: > Here's a blog post from John Rose explaining that exception throwing compiles to a goto in cases like this: > https://blogs.oracle.com/jrose/entry/longjumps_considered_inexpensive > > Sent from my phone > > On Jul 7, 2012 2:43 PM, "R?mi Forax" wrote: > On 07/07/2012 07:02 PM, Dain Sundstrom wrote: > > On Jul 7, 2012, at 1:56 AM, R?mi Forax wrote: > > > >> You have also to figure out how to get two return values from a method call, > >> but exceptions are your best friend here. > > Can you give an example of what you mean here? Also, from all the presentations I've seen on the JVM, exceptions are very expensive to throw and catch, so I would expect this to be way slower then say returning the multiple values using a generated results class. > > Exception are not expensive if you throw them and just catch them (and > don't use them) in the same inlining horizon, > so you can use them to implement non Java control flow without thinking > too much. > > Anyway, the idea here is to use exception as an exceptional mechanism by > example when > something that should be an int is not. In that case, throwing an > exception is not a big deal > because the VM will have to deopt which usual have a bigger impact on > the run time. > > > > > -dain > > R?mi > > _______________________________________________ > 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 mroos at roos.com Sat Jul 7 12:09:15 2012 From: mroos at roos.com (Mark Roos) Date: Sat, 7 Jul 2012 12:09:15 -0700 Subject: TaggedArrays (Proposal) In-Reply-To: <4FF7F9D3.6070901@univ-mlv.fr> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> <4FF756B5.4040003@univ-mlv.fr> <4FF7F9D3.6070901@univ-mlv.fr> Message-ID: Thanks R?mi, good example is big compared to the code of the generated assembler so the JIT may decide to not inline something I assume that changing the maxInline will fix this if its an issue You have also to figure out how to get two return values from a method call, but exceptions are your best friend here. I already do this for other ST patterns so no problem. thanks mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120707/dafc5eba/attachment.html From mroos at roos.com Sat Jul 7 12:09:15 2012 From: mroos at roos.com (Mark Roos) Date: Sat, 7 Jul 2012 12:09:15 -0700 Subject: JEP 160: Lambda-Form Representation for Method Handles In-Reply-To: <20120706221624.9C79AD3B@eggemoggin.niobe.net> References: <20120706221624.9C79AD3B@eggemoggin.niobe.net> Message-ID: Hi Mark, nice plan I was intrigued by the statement: Therefore, this work will provide a likely basis for efficient representation of the functional ?SAM? objects required by Project Lambda, and perhaps other future constructs, such as tuple objects or hybrid arrays But could I not find an up to date reference on what was intended here. Is there a place I can look? Particularly I was wondering on the difference between hybrid arrays and Jim L's TaggedArrays regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120707/f0f91e74/attachment.html From mroos at roos.com Sat Jul 7 14:44:13 2012 From: mroos at roos.com (Mark Roos) Date: Sat, 7 Jul 2012 14:44:13 -0700 Subject: TaggedArrays (Proposal) In-Reply-To: References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> <4FF756B5.4040003@univ-mlv.fr> <4FF7F9D3.6070901@univ-mlv.fr> Message-ID: Hi Dain I use exceptions to handle non local returns in ST which are not exceptional ( happen alot). I did a quick look at the timing and the throw/catch was not slow. I believe John Rose has a blog entry on it mark From: Dain Sundstrom To: Da Vinci Machine Project Date: 07/07/2012 10:10 AM Subject: Re: TaggedArrays (Proposal) Sent by: mlvm-dev-bounces at openjdk.java.net On Jul 7, 2012, at 1:56 AM, R?mi Forax wrote: > You have also to figure out how to get two return values from a method call, > but exceptions are your best friend here. Can you give an example of what you mean here? Also, from all the presentations I've seen on the JVM, exceptions are very expensive to throw and catch, so I would expect this to be way slower then say returning the multiple values using a generated results class. -dain _______________________________________________ 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/20120707/701d6868/attachment.html From headius at headius.com Sat Jul 7 14:45:11 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 7 Jul 2012 16:45:11 -0500 Subject: TaggedArrays (Proposal) In-Reply-To: <4FF883B7.7090405@univ-mlv.fr> References: <3C80C152-CAB7-41F9-AEB7-3446D336E9E2@me.com> <4FF630B8.8030400@univ-mlv.fr> <4FF756B5.4040003@univ-mlv.fr> <4FF7F9D3.6070901@univ-mlv.fr> <4FF883B7.7090405@univ-mlv.fr> Message-ID: On Sat, Jul 7, 2012 at 1:45 PM, R?mi Forax wrote: > Exception are not expensive if you throw them and just catch them (and > don't use them) in the same inlining horizon, > so you can use them to implement non Java control flow without thinking > too much. Important to note here that if they don't inline, you get considerably slower exception logic, so it's crucial that the exception throw and catch inline together. This is hard to guarantee on current VMs...and in fact this may be the most difficult aspect of writing low-level systems for the JVM right now (like language implementations): you can't make any guarantees. - Charlie From headius at headius.com Sat Jul 7 15:03:34 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 7 Jul 2012 17:03:34 -0500 Subject: Improving the performance of stacktrace generation Message-ID: Today I have a new conundrum for you all: I need stack trace generation on Hotspot to be considerably faster than it is now. In order to simulate many Ruby features, JRuby (over)uses Java stack traces. We recently (JRuby 1.6, about a year ago) moved to using the Java stack trace as the source of our Ruby backtrace information, mining out compiled frames and using interpreter markers to peel off interpreter frames. The result is that a Ruby trace with mixed compiled and interpreted code like this (https://gist.github.com/3068210) turns into this (https://gist.github.com/3068213). I consider this a great deal better than the plain Java trace, and I know other language implementers have lamented the verbosity of stack traces coming out of their languages. The unfortunate thing is that stack trace generation is very expensive in the JVM, and in order to generate normal exceptions and emulate other features we sometimes generate a lot of them. I think there's value in exploring how we can make stack trace generation cheaper at the JVM level. Here's a few cases in Ruby where we need to use Java stack traces to provide the same features: * Exceptions as non-exceptional or moderately-exceptional method results In this case I'm specifically thinking about Ruby's tendency to propagate errno values as exceptions; EAGAIN/EWOULDBLOCK for example are thrown from nonblocking IO methods when there's no data available. You will probably say "that's a horrible use for exceptions" and I agree. But there are a couple reasons why it's nicer too: - using return value sigils requires you to propagate them back out through many levels of calls - exception-handling is cleaner in code than having all your errno handling logic spliced into regular program flow In any case, the cost of generating a stack trace for potentially every non-blocking IO call is obviously too high. In JRuby, we default to having EAGAIN/EWOULDBLOCK exceptions not generate a stack trace, and you must pass a flag for them to do so. The justification is that these exceptions are almost always used to branch back to the top of a nonblocking IO loop, so the backtrace is useless. * Getting the current or previous method's name/file/line Ruby supports a number of features that allow you to get basic information about the method currently being executed or the method that called it. The most general of these features is the "caller" method, which provides an array of all method name + file + line that would appear in a stack trace at this point. This feature is often abused to get only the current or previous frame, and so in Ruby 1.9 they added __method__ to get the currently-executing method's name+file+line. In both cases, we must generate a full Java trace for these methods because the name of a method body is not necessarily statically known. We often want only the current frame or the current and previous frames, but we pay the cost of generating an entire Java stack trace to get them. * Warnings that actually report the line of code that triggered them In Ruby, it is possible to generate non-fatal warnings to stderr. In many cases, these warnings automatically include the file and line at which the triggering code lives. Because the warning logic is downstream from the Ruby code, we again must use a full Java stack trace to find the most recent (on stack) Ruby frame. This causes warnings to be as expensive as regular exceptions. Because the use of frame introspection (in this case through stack traces) has largely been ignored on current JVMs, I suspect there's a lot of improvement possible. At a minimum, the ability to only grab the top N frames from the stack trace could be a great improvement (Hotspot even has flags to restrict how large a trace it will generate, presumably to avoid the cost of accounting for deep stacks and generating traces from them). Any thoughts on this? Does anyone else have need for lighter-weight name/file/line inspection of the call stack? - Charlie From forax at univ-mlv.fr Sat Jul 7 15:31:12 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 08 Jul 2012 00:31:12 +0200 Subject: Improving the performance of stacktrace generation In-Reply-To: References: Message-ID: <4FF8B8B0.8070007@univ-mlv.fr> On 07/08/2012 12:03 AM, Charles Oliver Nutter wrote: > Today I have a new conundrum for you all: I need stack trace > generation on Hotspot to be considerably faster than it is now. > > In order to simulate many Ruby features, JRuby (over)uses Java stack > traces. We recently (JRuby 1.6, about a year ago) moved to using the > Java stack trace as the source of our Ruby backtrace information, > mining out compiled frames and using interpreter markers to peel off > interpreter frames. The result is that a Ruby trace with mixed > compiled and interpreted code like this > (https://gist.github.com/3068210) turns into this > (https://gist.github.com/3068213). I consider this a great deal better > than the plain Java trace, and I know other language implementers have > lamented the verbosity of stack traces coming out of their languages. > > The unfortunate thing is that stack trace generation is very expensive > in the JVM, and in order to generate normal exceptions and emulate > other features we sometimes generate a lot of them. I think there's > value in exploring how we can make stack trace generation cheaper at > the JVM level. > > Here's a few cases in Ruby where we need to use Java stack traces to > provide the same features: > > * Exceptions as non-exceptional or moderately-exceptional method results > > In this case I'm specifically thinking about Ruby's tendency to > propagate errno values as exceptions; EAGAIN/EWOULDBLOCK for example > are thrown from nonblocking IO methods when there's no data available. > > You will probably say "that's a horrible use for exceptions" and I > agree. But there are a couple reasons why it's nicer too: > - using return value sigils requires you to propagate them back out > through many levels of calls > - exception-handling is cleaner in code than having all your errno > handling logic spliced into regular program flow > > In any case, the cost of generating a stack trace for potentially > every non-blocking IO call is obviously too high. In JRuby, we default > to having EAGAIN/EWOULDBLOCK exceptions not generate a stack trace, > and you must pass a flag for them to do so. The justification is that > these exceptions are almost always used to branch back to the top of a > nonblocking IO loop, so the backtrace is useless. I don't see how to do more. > > * Getting the current or previous method's name/file/line > > Ruby supports a number of features that allow you to get basic > information about the method currently being executed or the method > that called it. The most general of these features is the "caller" > method, which provides an array of all method name + file + line that > would appear in a stack trace at this point. This feature is often > abused to get only the current or previous frame, and so in Ruby 1.9 > they added __method__ to get the currently-executing method's > name+file+line. > > In both cases, we must generate a full Java trace for these methods > because the name of a method body is not necessarily statically known. > We often want only the current frame or the current and previous > frames, but we pay the cost of generating an entire Java stack trace > to get them. You can use Throwable.getStackTraceElement() which is package visible and OpenJDK specific but at least it will be faster for all VMs that uses OpenJDK. > > * Warnings that actually report the line of code that triggered them > > In Ruby, it is possible to generate non-fatal warnings to stderr. In > many cases, these warnings automatically include the file and line at > which the triggering code lives. Because the warning logic is > downstream from the Ruby code, we again must use a full Java stack > trace to find the most recent (on stack) Ruby frame. This causes > warnings to be as expensive as regular exceptions. Please never optimize warnings, they are here to bug users until they fix the thing. So they should be slow :) > > Because the use of frame introspection (in this case through stack > traces) has largely been ignored on current JVMs, I suspect there's a > lot of improvement possible. At a minimum, the ability to only grab > the top N frames from the stack trace could be a great improvement > (Hotspot even has flags to restrict how large a trace it will > generate, presumably to avoid the cost of accounting for deep stacks > and generating traces from them). > > Any thoughts on this? Does anyone else have need for lighter-weight > name/file/line inspection of the call stack? > > - Charlie R?mi From headius at headius.com Sat Jul 7 15:50:35 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 7 Jul 2012 17:50:35 -0500 Subject: Improving the performance of stacktrace generation In-Reply-To: <4FF8B8B0.8070007@univ-mlv.fr> References: <4FF8B8B0.8070007@univ-mlv.fr> Message-ID: On Saturday, July 7, 2012, R?mi Forax wrote: > You can use Throwable.**getStackTraceElement() > which is package visible and OpenJDK specific but at least > it will be faster for all VMs that uses OpenJDK. > I'll certainly explore that to see if it improves the situation. If it's faster, it might be a way out in some circumstances. It seems like an official public API is needed here... Please never optimize warnings, they are here to bug users > > until they fix the thing. So they should be slow :) > Yes, except when *everyone else* has faster warnings than you. Then you're just giving people another reason to not use your stuff. Granted, JRuby is now becoming far and away the fastest Ruby implementation for exactly the reasons that stack traces are slow, but often making 90% of the code 5x faster but 10% of the code 100x slower means people give up on you without bothering. Remember, I agree with you...but I also feel like this attitude has allowed stack trace generation to avoid optimization effort for a long time, and there *are* useful things you can do with an introspectable call stack. - Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120707/344fdd9d/attachment.html From forax at univ-mlv.fr Sat Jul 7 16:57:45 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sun, 08 Jul 2012 01:57:45 +0200 Subject: Improving the performance of stacktrace generation In-Reply-To: References: <4FF8B8B0.8070007@univ-mlv.fr> Message-ID: <4FF8CCF9.2050402@univ-mlv.fr> On 07/08/2012 12:50 AM, Charles Oliver Nutter wrote: > On Saturday, July 7, 2012, R?mi Forax wrote: > > You can use Throwable.getStackTraceElement() > which is package visible and OpenJDK specific but at least > it will be faster for all VMs that uses OpenJDK. > > I'll certainly explore that to see if it improves the situation. If > it's faster, it might be a way out in some circumstances. > > It seems like an official public API is needed here... > > Please never optimize warnings, they are here to bug users > > until they fix the thing. So they should be slow :) > > > Yes, except when *everyone else* has faster warnings than you. Then > you're just giving people another reason to not use your stuff. > > Granted, JRuby is now becoming far and away the fastest Ruby > implementation for exactly the reasons that stack traces are slow, but > often making 90% of the code 5x faster but 10% of the code 100x slower > means people give up on you without bothering. > > Remember, I agree with you...but I also feel like this attitude has > allowed stack trace generation to avoid optimization effort for a long > time, and there *are* useful things you can do with an introspectable > call stack. Throwable.getStackTraceElement() let you walk the stack trace without generating the whole stack trace, in my opinion it's enough. BTW, I also think you are responsible too for the cost of generating stacktraces because the cost depends on the size of the stacktrace and an AST interpreter is a big consumer of stack frames. I am guilty too, PHP.reboot has the same issue and I try to mitigate that by avoiding to have an helper methods in the stacktrace of calls (not that easy without tailcall). > > - Charlie R?mi From john.r.rose at oracle.com Sat Jul 7 18:00:44 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 08 Jul 2012 01:00:44 +0000 Subject: hg: mlvm/mlvm/jdk: meth: cleanups Message-ID: <20120708010045.EE66E47E38@hg.openjdk.java.net> Changeset: f3998b83fe97 Author: jrose Date: 2012-07-07 18:00 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f3998b83fe97 meth: cleanups ! meth-lazy-7023639.patch From john.r.rose at oracle.com Sat Jul 7 22:03:54 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 08 Jul 2012 05:03:54 +0000 Subject: hg: mlvm/mlvm/hotspot: rebase to current hsx/hotspot-comp Message-ID: <20120708050354.ACAC747E48@hg.openjdk.java.net> Changeset: b06d7d2b0f2f Author: jrose Date: 2012-07-07 22:03 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b06d7d2b0f2f rebase to current hsx/hotspot-comp ! series From john.r.rose at oracle.com Sat Jul 7 22:06:51 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 08 Jul 2012 05:06:51 +0000 Subject: hg: mlvm/mlvm/jdk: rebase to current hsx/hotspot-comp; add contributed draft for 7177472 Message-ID: <20120708050651.7976747E4B@hg.openjdk.java.net> Changeset: 9b610da8ef26 Author: jrose Date: 2012-07-07 22:06 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/9b610da8ef26 rebase to current hsx/hotspot-comp; add contributed draft for 7177472 + meth-7177472.patch - meth-experiment.patch ! meth-lazy-7023639.patch ! series From mroos at roos.com Sat Jul 7 23:22:33 2012 From: mroos at roos.com (Mark Roos) Date: Sat, 7 Jul 2012 23:22:33 -0700 Subject: Improving the performance of stacktrace generation In-Reply-To: References: Message-ID: >From Charile Any thoughts on this? Does anyone else have need for lighter-weight name/file/line inspection of the call stack? Yeah I need it for my debugger and error displays. But I need it for suspended threads ( my debugging steps ) as well as for exceptions. And for exceptions it would be nice to access the stack vars as well. Currently I have a debug agent I use to help with this but it would be nice if I didn't. I'll probably look at Lukas' coroutines for this eventually. regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120707/36369a06/attachment.html From john.r.rose at oracle.com Sun Jul 8 01:25:01 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 08 Jul 2012 08:25:01 +0000 Subject: hg: mlvm/mlvm/jdk: meth: misc fixes Message-ID: <20120708082502.7473B47E54@hg.openjdk.java.net> Changeset: 66fc717f4da1 Author: jrose Date: 2012-07-08 01:24 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/66fc717f4da1 meth: misc fixes ! meth-lazy-7023639.patch ! meth-lazy-7023639.xbmh.patch From john.r.rose at oracle.com Sun Jul 8 01:25:26 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 08 Jul 2012 08:25:26 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: misc fixes Message-ID: <20120708082527.C45A447E57@hg.openjdk.java.net> Changeset: 01bca62ccfe7 Author: jrose Date: 2012-07-08 01:25 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/01bca62ccfe7 meth: misc fixes ! meth-lazy-7023639.jit.patch ! meth-lazy-7023639.patch From john.r.rose at oracle.com Sun Jul 8 02:11:01 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 08 Jul 2012 09:11:01 +0000 Subject: hg: mlvm/mlvm/jdk: meth: jcheck cleanup Message-ID: <20120708091102.43F6947E5A@hg.openjdk.java.net> Changeset: 6047f8490f1f Author: jrose Date: 2012-07-08 02:10 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/6047f8490f1f meth: jcheck cleanup ! meth-lazy-7023639.patch ! meth-lazy-7023639.xbmh.patch From john.r.rose at oracle.com Sun Jul 8 02:24:06 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 08 Jul 2012 09:24:06 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: jcheck cleanup; tweaks Message-ID: <20120708092407.7B0CB47E5E@hg.openjdk.java.net> Changeset: a1bae6849a0b Author: jrose Date: 2012-07-08 02:23 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a1bae6849a0b meth: jcheck cleanup; tweaks ! meth-lazy-7023639.jit.patch ! meth-lazy-7023639.patch From john.r.rose at oracle.com Tue Jul 10 01:42:45 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 10 Jul 2012 08:42:45 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering Message-ID: <20120710084246.4DA2147ED3@hg.openjdk.java.net> Changeset: 851ca5831589 Author: jrose Date: 2012-07-10 01:42 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/851ca5831589 meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering ! meth-lazy-7023639.patch From forax at univ-mlv.fr Tue Jul 10 02:12:47 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 10 Jul 2012 11:12:47 +0200 Subject: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering In-Reply-To: <20120710084246.4DA2147ED3@hg.openjdk.java.net> References: <20120710084246.4DA2147ED3@hg.openjdk.java.net> Message-ID: <4FFBF20F.7090600@univ-mlv.fr> On 07/10/2012 10:42 AM, john.r.rose at oracle.com wrote: > Changeset: 851ca5831589 > Author: jrose > Date: 2012-07-10 01:42 -0700 > URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/851ca5831589 > > meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering > > ! meth-lazy-7023639.patch I think backtrace filtering, should be enhanced by adding a new method attribute in the bytecode that indicates if a method should be visible or not when dumping a stacktrace and a display name that should be used instead of the bytecode method name. This may reduce the need of stacktrace post-processing and makes Charles happy. R?mi From glaforge at gmail.com Tue Jul 10 03:10:22 2012 From: glaforge at gmail.com (Guillaume Laforge) Date: Tue, 10 Jul 2012 12:10:22 +0200 Subject: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering In-Reply-To: <4FFBF20F.7090600@univ-mlv.fr> References: <20120710084246.4DA2147ED3@hg.openjdk.java.net> <4FFBF20F.7090600@univ-mlv.fr> Message-ID: It'd be useful for others as well :-) On Tue, Jul 10, 2012 at 11:12 AM, R?mi Forax wrote: > On 07/10/2012 10:42 AM, john.r.rose at oracle.com wrote: > > Changeset: 851ca5831589 > > Author: jrose > > Date: 2012-07-10 01:42 -0700 > > URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/851ca5831589 > > > > meth: fix to intrinsic compilation; assembler tweaks for debugging; > backtrace filtering > > > > ! meth-lazy-7023639.patch > > I think backtrace filtering, should be enhanced by adding a new method > attribute in the bytecode that indicates if a method should be visible > or not > when dumping a stacktrace and a display name that should be used > instead of the bytecode method name. > > This may reduce the need of stacktrace post-processing and makes Charles > happy. > > R?mi > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Guillaume Laforge Groovy Project Manager SpringSource, a division of VMware Blog: http://glaforge.appspot.com/ Social: @glaforge / Google+ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120710/fd0a399b/attachment.html From michael.haupt at oracle.com Tue Jul 10 04:46:17 2012 From: michael.haupt at oracle.com (michael.haupt at oracle.com) Date: Tue, 10 Jul 2012 11:46:17 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: more robust XBMH creation/cloning, refactoring Message-ID: <20120710114618.D636347EED@hg.openjdk.java.net> Changeset: 0045d0c0a3d2 Author: mhaupt Date: 2012-07-10 13:46 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/0045d0c0a3d2 meth-lazy: more robust XBMH creation/cloning, refactoring ! meth-lazy-7023639.xbmh.patch From john.r.rose at oracle.com Tue Jul 10 10:05:20 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 10 Jul 2012 10:05:20 -0700 Subject: OSX port In-Reply-To: References: <06E1B1D8-8C6A-409B-BB2C-0313A4765613@gmail.com> <30DB491D-6A1B-41D9-B57C-A629716D7E1C@oracle.com> Message-ID: On Jul 4, 2012, at 11:46 PM, Henri Gomez wrote: > What's current build process to be used ? It appears that JDK 8 needs to be built with a JDK 8 release. (I don't have any information about whether this is intentional or why it is.) Below are some recent changes I've made to my copy of build.sh, including a setting of ALT_BOOTDIR. Another form of build breakage may show up also, if you use a very new JDK 8 release to build with. Some recent builds of javac get this error when building the new meth-lazy stuff: > /Users/jrose/Projects/davinci/sources/jdk/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java:37: error: package com.sun.xml.internal.ws.org.objectweb.asm does not exist > import com.sun.xml.internal.ws.org.objectweb.asm.*; I haven't tracked down this bug, but it may be a change in the way javac performs filtering on rt.jar. My workaround is to use a slightly older version of JDK 8 to build with. I hope this helps... ? John diff -ru build.sh.~5~ build.sh --- build.sh.~5~ 2012-02-15 23:45:46.000000000 -0800 +++ build.sh 2012-07-07 21:59:34.000000000 -0700 @@ -21,7 +21,9 @@ #export ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 #export ALT_BOOTDIR=/usr/local/soylatte16-amd64-1.0.3 #export ALT_BOOTDIR=$JAVA7X_HOME -export ALT_BOOTDIR=$DAVINCI/sources/build-stable-bootstrap-0623/bsd-i586/j2sdk-image +#export ALT_BOOTDIR=$DAVINCI/sources/build-stable-bootstrap-0623/bsd-amd64/j2sdk-image +#export ALT_BOOTDIR=$HOME/env/JAVA7_HOME +export ALT_BOOTDIR=$HOME/env/JAVA8_HOME #for solaris hack this file: ./jdk/src/solaris/javavm/export/machine/endian.h @@ -40,11 +42,10 @@ ALT_JIBX_LIBS_PATH=$HOME/Downloads/jibx/lib ALT_JDK_IMPORT_PATH=$ALT_BOOTDIR ALT_BOOTDIR=$ALT_BOOTDIR - ALT_BINARY_PLUGS_PATH=$HOME/Downloads/JDK7/jdk-7-icedtea-plugs - ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include - ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib ANT_HOME=/usr/share/ant NO_DOCS=true + NO_DEMOS=true + NO_SAMPLES=true HOTSPOT_BUILD_JOBS=2 BUILD_LANGTOOLS=true BUILD_HOTSPOT=true @@ -58,8 +62,8 @@ LD_LIBRARY_PATH= COMMAND_MODE=unix2003 OPENJDK=true - CC=gcc-4.2 - CXX=g++-4.2 + CC=$( xcrun -find gcc ) + CXX=$( xcrun -find g++ ) " # MACOSX_UNIVERSAL=false -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120710/28b0263c/attachment.html From blackdrag at gmx.org Tue Jul 10 13:07:50 2012 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 10 Jul 2012 22:07:50 +0200 Subject: How to making Class.forName work in indy? Message-ID: <4FFC8B96.7030906@gmx.org> Hi all, assuming you have to compile code with indy that realizes this: Class.forName(x) Meaning, we want to execute forName from Class using invokedynamic. If you then have frames in your trace looking like this: > java.lang.Class.forName0(Native Method) > java.lang.Class.forName(Class.java:186) > java.lang.invoke.MethodHandleImpl$GuardWithCatch.invoke_L2(MethodHandleImpl.java:1130) > org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:680) > groovy.util.JavadocAssertionTestSuite.(JavadocAssertionTestSuite.groovy:71) then it is clear to me, why it is failing. At least the Indyinterface part, if not even the GuradWithCatch part are disturbing the stack walking Class#forName is using. has anyone any idea on how to make this work across JVMs? One version, that sounds quite crazy to me, but may just work, is to compile a helper method on the class, that directly calls Class#forName and thus making it work, since there is no longer a wrong stack frame at the position Class#forName is looking for. But well... it may be a possibility bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From john.r.rose at oracle.com Tue Jul 10 13:25:37 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 10 Jul 2012 20:25:37 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: assembler tweaks Message-ID: <20120710202537.C817247F10@hg.openjdk.java.net> Changeset: 93e8421c14a6 Author: jrose Date: 2012-07-10 13:25 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/93e8421c14a6 meth: assembler tweaks ! meth-lazy-7023639.patch From forax at univ-mlv.fr Tue Jul 10 13:56:45 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 10 Jul 2012 22:56:45 +0200 Subject: How to making Class.forName work in indy? In-Reply-To: <4FFC8B96.7030906@gmx.org> References: <4FFC8B96.7030906@gmx.org> Message-ID: <4FFC970D.1040006@univ-mlv.fr> On 07/10/2012 10:07 PM, Jochen Theodorou wrote: > Hi all, > > assuming you have to compile code with indy that realizes this: > > Class.forName(x) > > Meaning, we want to execute forName from Class using invokedynamic. If > you then have frames in your trace looking like this: > >> java.lang.Class.forName0(Native Method) >> java.lang.Class.forName(Class.java:186) >> java.lang.invoke.MethodHandleImpl$GuardWithCatch.invoke_L2(MethodHandleImpl.java:1130) >> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:680) >> groovy.util.JavadocAssertionTestSuite.(JavadocAssertionTestSuite.groovy:71) > then it is clear to me, why it is failing. At least the Indyinterface > part, if not even the GuradWithCatch part are disturbing the stack > walking Class#forName is using. > > has anyone any idea on how to make this work across JVMs? One version, > that sounds quite crazy to me, but may just work, is to compile a helper > method on the class, that directly calls Class#forName and thus making > it work, since there is no longer a wrong stack frame at the position > Class#forName is looking for. But well... it may be a possibility > > bye Jochen > Class.forName(name) is equivalent to Class.forName(name, true, lookup.lookupClass().getClassLoader()) As true and lookup.lookupClass().getClassLoader() are constant in the BSM, you can bound them using insertArguments. R?mi || From blackdrag at gmx.org Tue Jul 10 13:57:33 2012 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 10 Jul 2012 22:57:33 +0200 Subject: How to making Class.forName work in indy? In-Reply-To: <4FFC970D.1040006@univ-mlv.fr> References: <4FFC8B96.7030906@gmx.org> <4FFC970D.1040006@univ-mlv.fr> Message-ID: <4FFC973D.1020303@gmx.org> Am 10.07.2012 22:56, schrieb R?mi Forax: [...] > Class.forName(name) is equivalent to Class.forName(name, true, > lookup.lookupClass().getClassLoader()) > As true and lookup.lookupClass().getClassLoader() are constant in the BSM, > you can bound them using insertArguments. also an interesting idea, true, never thought of that... which is exactly why I ask here ;) bye blackdrag -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From christian.thalinger at oracle.com Tue Jul 10 18:31:12 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 11 Jul 2012 01:31:12 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: misc. compiler fixes Message-ID: <20120711013113.3359E47F29@hg.openjdk.java.net> Changeset: edfc23d84113 Author: twisti Date: 2012-07-10 18:30 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/edfc23d84113 meth-lazy: misc. compiler fixes ! meth-lazy-7023639.jit.patch From john.r.rose at oracle.com Tue Jul 10 22:42:07 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 11 Jul 2012 05:42:07 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: merge in jit patch; passes jtreg tests in C1, C2, and Tiered modes Message-ID: <20120711054207.801F947F4B@hg.openjdk.java.net> Changeset: 747688368d8f Author: jrose Date: 2012-07-10 22:42 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/747688368d8f meth: merge in jit patch; passes jtreg tests in C1, C2, and Tiered modes ! meth-lazy-7023639.jit.patch ! meth-lazy-7023639.patch ! series From john.r.rose at oracle.com Tue Jul 10 23:19:11 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 11 Jul 2012 06:19:11 +0000 Subject: hg: mlvm/mlvm/jdk: meth: add @Hidden annotations Message-ID: <20120711061912.00D6A47F4E@hg.openjdk.java.net> Changeset: 77f38b00af98 Author: jrose Date: 2012-07-10 23:19 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/77f38b00af98 meth: add @Hidden annotations ! meth-lazy-7023639.patch ! meth-lazy-7023639.xbmh.patch From john.r.rose at oracle.com Tue Jul 10 23:31:06 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 11 Jul 2012 06:31:06 +0000 Subject: hg: mlvm/mlvm/hotspot: annot, meth: prepare for review Message-ID: <20120711063107.112BF47F55@hg.openjdk.java.net> Changeset: a3fedaf25c6d Author: jrose Date: 2012-07-10 23:31 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a3fedaf25c6d annot, meth: prepare for review + annot-6711908.patch - annot-inline.patch - annot.patch ! series From john.r.rose at oracle.com Tue Jul 10 23:31:37 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 11 Jul 2012 06:31:37 +0000 Subject: hg: mlvm/mlvm/hotspot: annot, meth: recategorize Message-ID: <20120711063137.EE6FB47F56@hg.openjdk.java.net> Changeset: 2ebbc5f13bb6 Author: jrose Date: 2012-07-10 23:31 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/2ebbc5f13bb6 annot, meth: recategorize ! series From john.r.rose at oracle.com Tue Jul 10 23:36:41 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 10 Jul 2012 23:36:41 -0700 Subject: review request (M): 6711908: JVM needs direct access to some annotations Message-ID: This is a building block for an upcoming large enhancement for method handles. http://cr.openjdk.java.net/~jrose/6711908/webrev.00 The implemented interface is completely private to the java.lang.invoke package. ? John From michael.haupt at oracle.com Wed Jul 11 00:01:02 2012 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 11 Jul 2012 09:01:02 +0200 Subject: review request (M): 6711908: JVM needs direct access to some annotations In-Reply-To: References: Message-ID: <12DDFD82-2442-4D4A-96BF-B8DF2E2310C4@oracle.com> Hi John, Am 11.07.2012 um 08:36 schrieb John Rose: > http://cr.openjdk.java.net/~jrose/6711908/webrev.00 two things (no big deals) in classFileParser.cpp: @@ -1636,16 +1648,163 @@ The code for parsing @Retention deserves a comment highlighting that it is about parsing an annotation with payload (none of the annotations introduced by our work do this). @@ -2560,10 +2727,11 @@ TempNewSymbol sde_symbol is never used. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120711/e45527ef/attachment.html From forax at univ-mlv.fr Wed Jul 11 02:20:23 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 11 Jul 2012 11:20:23 +0200 Subject: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering In-Reply-To: References: <20120710084246.4DA2147ED3@hg.openjdk.java.net> <4FFBF20F.7090600@univ-mlv.fr> Message-ID: <4FFD4557.1000903@univ-mlv.fr> On 07/10/2012 12:10 PM, Guillaume Laforge wrote: > It'd be useful for others as well :-) Yes, for JRuby which is mixed mode (AST walker + bytecode compiler), you still have to do some post processing but for Groovy which is compiled only, I think you can avoid any processing at runtime if you post process the groovy.jar at compile time (because Hidden is not a public annotation) :) R?mi > > On Tue, Jul 10, 2012 at 11:12 AM, R?mi Forax > wrote: > > On 07/10/2012 10:42 AM, john.r.rose at oracle.com > wrote: > > Changeset: 851ca5831589 > > Author: jrose > > Date: 2012-07-10 01:42 -0700 > > URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/851ca5831589 > > > > meth: fix to intrinsic compilation; assembler tweaks for > debugging; backtrace filtering > > > > ! meth-lazy-7023639.patch > > I think backtrace filtering, should be enhanced by adding a new method > attribute in the bytecode that indicates if a method should be visible > or not > when dumping a stacktrace and a display name that should be used > instead of the bytecode method name. > > This may reduce the need of stacktrace post-processing and makes > Charles > happy. > > R?mi > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > > > -- > Guillaume Laforge > Groovy Project Manager > SpringSource, a division of VMware > > Blog: http://glaforge.appspot.com/ > Social: @glaforge / Google+ > > > > > _______________________________________________ > 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 Wed Jul 11 02:29:14 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 11 Jul 2012 11:29:14 +0200 Subject: hg: mlvm/mlvm/jdk: meth: add @Hidden annotations In-Reply-To: <20120711061912.00D6A47F4E@hg.openjdk.java.net> References: <20120711061912.00D6A47F4E@hg.openjdk.java.net> Message-ID: <4FFD476A.6010404@univ-mlv.fr> On 07/11/2012 08:19 AM, john.r.rose at oracle.com wrote: > Changeset: 77f38b00af98 > Author: jrose > Date: 2012-07-10 23:19 -0700 > URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/77f38b00af98 > > meth: add @Hidden annotations > > ! meth-lazy-7023639.patch > ! meth-lazy-7023639.xbmh.patch just a question, even if it's not a big deal if one is able to generate bytecode, why Hidden is not a top level type of java.lang.invoke ? R?mi From john.r.rose at oracle.com Wed Jul 11 04:39:49 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 11 Jul 2012 11:39:49 +0000 Subject: hg: mlvm/mlvm/langtools: rebase to current hsx/hotspot-comp Message-ID: <20120711113949.8422147F67@hg.openjdk.java.net> Changeset: 8f3a51eebb83 Author: jrose Date: 2012-07-11 04:39 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/8f3a51eebb83 rebase to current hsx/hotspot-comp ! series From john.r.rose at oracle.com Wed Jul 11 04:51:53 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 11 Jul 2012 11:51:53 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: simplify invokedynamic linkage paths; remove cpCache entry race condition Message-ID: <20120711115154.0345847F6A@hg.openjdk.java.net> Changeset: 89687e50c4e9 Author: jrose Date: 2012-07-11 04:51 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/89687e50c4e9 meth: simplify invokedynamic linkage paths; remove cpCache entry race condition ! meth-lazy-7023639.patch From henri.gomez at gmail.com Wed Jul 11 04:52:06 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 11 Jul 2012 13:52:06 +0200 Subject: OSX port In-Reply-To: References: <06E1B1D8-8C6A-409B-BB2C-0313A4765613@gmail.com> <30DB491D-6A1B-41D9-B57C-A629716D7E1C@oracle.com> Message-ID: Thanks John. Could you provide me link or copy of your build.sh ? Cheers 2012/7/10 John Rose : > On Jul 4, 2012, at 11:46 PM, Henri Gomez wrote: > > What's current build process to be used ? > > > It appears that JDK 8 needs to be built with a JDK 8 release. (I don't have > any information about whether this is intentional or why it is.) > > Below are some recent changes I've made to my copy of build.sh, including a > setting of ALT_BOOTDIR. > > Another form of build breakage may show up also, if you use a very new JDK 8 > release to build with. Some recent builds of javac get this error when > building the new meth-lazy stuff: > > /Users/jrose/Projects/davinci/sources/jdk/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java:37: > error: package com.sun.xml.internal.ws.org.objectweb.asm does not exist > import com.sun.xml.internal.ws.org.objectweb.asm.*; > > > I haven't tracked down this bug, but it may be a change in the way javac > performs filtering on rt.jar. My workaround is to use a slightly older > version of JDK 8 to build with. > > I hope this helps... > ? John > > > diff -ru build.sh.~5~ build.sh > --- build.sh.~5~ 2012-02-15 23:45:46.000000000 -0800 > +++ build.sh 2012-07-07 21:59:34.000000000 -0700 > @@ -21,7 +21,9 @@ > #export ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 > #export ALT_BOOTDIR=/usr/local/soylatte16-amd64-1.0.3 > #export ALT_BOOTDIR=$JAVA7X_HOME > -export > ALT_BOOTDIR=$DAVINCI/sources/build-stable-bootstrap-0623/bsd-i586/j2sdk-image > +#export > ALT_BOOTDIR=$DAVINCI/sources/build-stable-bootstrap-0623/bsd-amd64/j2sdk-image > +#export ALT_BOOTDIR=$HOME/env/JAVA7_HOME > +export ALT_BOOTDIR=$HOME/env/JAVA8_HOME > > #for solaris hack this file: > ./jdk/src/solaris/javavm/export/machine/endian.h > > @@ -40,11 +42,10 @@ > ALT_JIBX_LIBS_PATH=$HOME/Downloads/jibx/lib > ALT_JDK_IMPORT_PATH=$ALT_BOOTDIR > ALT_BOOTDIR=$ALT_BOOTDIR > - ALT_BINARY_PLUGS_PATH=$HOME/Downloads/JDK7/jdk-7-icedtea-plugs > - ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include > - ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib > ANT_HOME=/usr/share/ant > NO_DOCS=true > + NO_DEMOS=true > + NO_SAMPLES=true > HOTSPOT_BUILD_JOBS=2 > BUILD_LANGTOOLS=true > BUILD_HOTSPOT=true > @@ -58,8 +62,8 @@ > LD_LIBRARY_PATH= > COMMAND_MODE=unix2003 > OPENJDK=true > - CC=gcc-4.2 > - CXX=g++-4.2 > + CC=$( xcrun -find gcc ) > + CXX=$( xcrun -find g++ ) > " > > # MACOSX_UNIVERSAL=false > > > > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From john.r.rose at oracle.com Wed Jul 11 04:52:04 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 11 Jul 2012 11:52:04 +0000 Subject: hg: mlvm/mlvm/jdk: meth: simplify invokedynamic linkage paths Message-ID: <20120711115205.5A34547F6B@hg.openjdk.java.net> Changeset: e3ce088d7958 Author: jrose Date: 2012-07-11 04:52 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e3ce088d7958 meth: simplify invokedynamic linkage paths ! meth-lazy-7023639.patch From stephen.bannasch at deanbrook.org Wed Jul 11 09:27:00 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 11 Jul 2012 12:27:00 -0400 Subject: OSX port In-Reply-To: References: <06E1B1D8-8C6A-409B-BB2C-0313A4765613@gmail.com> <30DB491D-6A1B-41D9-B57C-A629716D7E1C@oracle.com> Message-ID: Hi Henri By setting ALT_BOOTDIR and ALT_JDK_IMPORT_PATH to use a recent Java 1.8 build (from last week, 2012_07_07) my mlvm now compiles and runs fine on 10.6.8 Updated script here: https://gist.github.com/243072 Am running following jtreg tests: jdk/test/java/lang/invoke/ jdk/test/java/dyn/CoroutineTest.java Also testing GUI (is X11 linked in properly) by running /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar latest build uploaded here: http://www.concord.org/~sbannasch/mlvm/java-1.8.0-internal-mlvm-2012_07_11.tar.gz From dain at iq80.com Wed Jul 11 10:26:33 2012 From: dain at iq80.com (Dain Sundstrom) Date: Wed, 11 Jul 2012 10:26:33 -0700 Subject: OSX port In-Reply-To: References: <06E1B1D8-8C6A-409B-BB2C-0313A4765613@gmail.com> <30DB491D-6A1B-41D9-B57C-A629716D7E1C@oracle.com> Message-ID: <7E880DC4-40F2-4715-8A81-DEDDA52C5C12@iq80.com> Does this build contain the coro patch? -dain On Jul 11, 2012, at 9:27 AM, Stephen Bannasch wrote: > Hi Henri > > By setting ALT_BOOTDIR and ALT_JDK_IMPORT_PATH to use a recent Java 1.8 build (from last week, 2012_07_07) my mlvm now compiles > and runs fine on 10.6.8 > > Updated script here: https://gist.github.com/243072 > > Am running following jtreg tests: > > jdk/test/java/lang/invoke/ > jdk/test/java/dyn/CoroutineTest.java > > Also testing GUI (is X11 linked in properly) by running /Developer/Extras/Java/JFC/SwingSet2/SwingSet2.jar > > latest build uploaded here: > http://www.concord.org/~sbannasch/mlvm/java-1.8.0-internal-mlvm-2012_07_11.tar.gz > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From michael.haupt at oracle.com Wed Jul 11 13:07:40 2012 From: michael.haupt at oracle.com (michael.haupt at oracle.com) Date: Wed, 11 Jul 2012 20:07:40 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding Message-ID: <20120711200740.DA60847F94@hg.openjdk.java.net> Changeset: 79c955d995f0 Author: mhaupt Date: 2012-07-11 22:07 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/79c955d995f0 meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding ! meth-lazy-7023639.xbmh.patch From john.r.rose at oracle.com Wed Jul 11 13:24:09 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 11 Jul 2012 13:24:09 -0700 Subject: hg: mlvm/mlvm/jdk: meth: add @Hidden annotations In-Reply-To: <4FFD476A.6010404@univ-mlv.fr> References: <20120711061912.00D6A47F4E@hg.openjdk.java.net> <4FFD476A.6010404@univ-mlv.fr> Message-ID: On Jul 11, 2012, at 2:29 AM, R?mi Forax wrote: > just a question, even if it's not a big deal if one is able to generate > bytecode, > why Hidden is not a top level type of java.lang.invoke ? Good question. The answer is that hiding of stack frames is limited to hiding method handle implementation details. Specifically, the frames that are to be hidden are those which are not specified by the JSR 292 modifications to the JVMS. For example, if you have z=filterReturnValue(::x,::y), and some method m does z.invoke(), the visible stack frames will be m calling x and m calling y. Internally there will be a continuation during the call to x which waits to apply y. This must be some sort of activation frame, but the JVMS requires it to be hidden. In JDK 7 it was a ricochet frame (hand assembly code) and in JDK 8 it will be a lambda form activation (bytecode). Both must be suppressed in backtraces. A general Lisp-machine-style convention for redacting back traces would be interesting, but it would also require a new JSR. On the other hand, Hidden could be top-level. It's a matter of coding taste. Binding it to LF makes it more clear that it has a specific use. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120711/54c2698b/attachment.html From headius at headius.com Wed Jul 11 13:32:23 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 11 Jul 2012 13:32:23 -0700 Subject: Testing out latest work Message-ID: Ok, gents, Christian told me now might be a good time to start poking at the new indy backend with JRuby, so I got a build together and have been playing with it a bit. First off, getting it to build... Stephen B's gist still works fine: https://gist.github.com/243072 But I had to issue one additional command to get xcode tools in the right places for command-line build of OpenJDK: sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer This is latest Lion and Xcode (4.3.2). I previously installed the command-line tools through the Xcode interface. OK...so the next thing was getting the patches to apply. I essentially just disabled coro and removed -testable and -/meth from all meth-related patches. I'm not sure if this is the right list, but here's what actually applied before the build: https://gist.github.com/faf4437f5985828f3111 With that, I was able to build and things started to run. But not for long! :) First thing I tested was fib, and it ran incredibly slow...like 3 orders of magnitude slow. So I figured it must not be compiling. Turned on -XX:+PrintCompilation, got an AIOOB exception. Turned it off, consistently getting either segfaults or an AIOOB exception. Here's a couple dumps (exception during PrintCompilation, segfault, exception): https://gist.github.com/5ecfacea1a3f23ceaf9f So there it is for the moment :) Thoughts? - Charlie From john.r.rose at oracle.com Wed Jul 11 13:34:03 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 11 Jul 2012 13:34:03 -0700 Subject: OSX port In-Reply-To: References: <06E1B1D8-8C6A-409B-BB2C-0313A4765613@gmail.com> <30DB491D-6A1B-41D9-B57C-A629716D7E1C@oracle.com> Message-ID: <07790822-0CE8-4B94-988C-6E50BEC9303A@oracle.com> On Jul 11, 2012, at 4:52 AM, Henri Gomez wrote: > Could you provide me link or copy of your build.sh ? For what it's worth, I've refreshed my posting of build.sh: https://gist.github.com/118516 ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120711/82bc5243/attachment.html From headius at headius.com Wed Jul 11 13:35:00 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 11 Jul 2012 13:35:00 -0700 Subject: Testing out latest work In-Reply-To: References: Message-ID: FYI, this is a build from roughly 8AM CDT today. I don't think any patches have landed post-build. - Charlie On Wed, Jul 11, 2012 at 1:32 PM, Charles Oliver Nutter wrote: > Ok, gents, Christian told me now might be a good time to start poking > at the new indy backend with JRuby, so I got a build together and have > been playing with it a bit. > > First off, getting it to build... > > Stephen B's gist still works fine: https://gist.github.com/243072 > > But I had to issue one additional command to get xcode tools in the > right places for command-line build of OpenJDK: > > sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer > > This is latest Lion and Xcode (4.3.2). I previously installed the > command-line tools through the Xcode interface. > > OK...so the next thing was getting the patches to apply. I essentially > just disabled coro and removed -testable and -/meth from all > meth-related patches. I'm not sure if this is the right list, but > here's what actually applied before the build: > https://gist.github.com/faf4437f5985828f3111 > > With that, I was able to build and things started to run. But not for long! :) > > First thing I tested was fib, and it ran incredibly slow...like 3 > orders of magnitude slow. So I figured it must not be compiling. > Turned on -XX:+PrintCompilation, got an AIOOB exception. Turned it > off, consistently getting either segfaults or an AIOOB exception. > > Here's a couple dumps (exception during PrintCompilation, segfault, > exception): https://gist.github.com/5ecfacea1a3f23ceaf9f > > So there it is for the moment :) Thoughts? > > - Charlie From forax at univ-mlv.fr Wed Jul 11 13:48:38 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 11 Jul 2012 22:48:38 +0200 Subject: hg: mlvm/mlvm/jdk: meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding In-Reply-To: <20120711200740.DA60847F94@hg.openjdk.java.net> References: <20120711200740.DA60847F94@hg.openjdk.java.net> Message-ID: <4FFDE6A6.2020504@univ-mlv.fr> On 07/11/2012 10:07 PM, michael.haupt at oracle.com wrote: > Changeset: 79c955d995f0 > Author: mhaupt > Date: 2012-07-11 22:07 +0200 > URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/79c955d995f0 > > meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding > > ! meth-lazy-7023639.xbmh.patch > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev Hi Mickael, some minor comments, makeSignature should use a StringBuilder and not a StringBuffer. ans I don't think generateConcreteBMHClass needs to return a Class, a Class seems enough so the cast near the end of the method can be removed. R?mi From henri.gomez at gmail.com Wed Jul 11 13:47:01 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 11 Jul 2012 22:47:01 +0200 Subject: OSX port In-Reply-To: <07790822-0CE8-4B94-988C-6E50BEC9303A@oracle.com> References: <06E1B1D8-8C6A-409B-BB2C-0313A4765613@gmail.com> <30DB491D-6A1B-41D9-B57C-A629716D7E1C@oracle.com> <07790822-0CE8-4B94-988C-6E50BEC9303A@oracle.com> Message-ID: Thanks to all. I'll update my build script and produce a new MLVM for OSX, in fastdebug mode (I don't forget R?my :) 2012/7/11 John Rose : > On Jul 11, 2012, at 4:52 AM, Henri Gomez wrote: > > Could you provide me link or copy of your build.sh ? > > > For what it's worth, I've refreshed my posting of build.sh: > https://gist.github.com/118516 > > ? John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From john.r.rose at oracle.com Wed Jul 11 13:46:54 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 11 Jul 2012 13:46:54 -0700 Subject: Testing out latest work In-Reply-To: References: Message-ID: On Jul 11, 2012, at 1:35 PM, Charles Oliver Nutter wrote: > So there it is for the moment :) Thoughts? Thanks for testing. Sorry it didn't get so far! I think we have a depot bug and/or race condition. It may be that more cores make the bug happen more. I am able to grind through things like bench/bench_red_black.rb in several modes, such as [1]. Yes, it is slow, so something is out of tune. We are going for correctness at the moment. ? John [1] Is this a good test? $ JAVA_HOME=$JAVA8X_BUILD bin/jruby -J-Xbootclasspath/p:$METH_BUILD/classes -J-ea -J-esa -J-XX:+ShowMessageBoxOnError -J-showversion -J-d64 -J-Xbatch -J-XX:+TieredCompilation -J-XX:-UseCompressedOops -J-XX:+UnlockDiagnosticVMOptions -J-XX:+LogCompilation -J-XX:+PrintCompilation -X+C bench/bench_red_black.rb 4 1595 1 b 3 java.lang.Integer::rotateLeft (9 bytes) 1605 2 b 1 java.lang.Integer::rotateLeft (9 bytes) 1607 1 3 java.lang.Integer::rotateLeft (9 bytes) made not entrant 1609 3 b 3 java.util.Hashtable::hash (48 bytes) Warning: TraceDependencies results may be inflated by VerifyDependencies openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-jrose_2012_07_08_02_30-b00) 1622 4 n 0 java.lang.System::arraycopy (native) (static) OpenJDK 64-Bit Server VM (build 24.0-b16-jvmg, mixed mode) 1633 5 b 3 java.lang.Object:: (1 bytes) 1645 6 b 3 java.lang.String::charAt (29 bytes) 1654 7 b 3 java.lang.String::indexOf (70 bytes) 1667 8 b 3 java.lang.String::length (6 bytes) 1669 9 b 3 java.lang.Math::min (11 bytes) 1673 10 b 3 java.lang.AbstractStringBuilder::ensureCapacityInternal (16 bytes) 1697 11 b 3 java.lang.String::equals (81 bytes) 1749 12 b 3 sun.misc.Hashing::murmur3_32 (188 bytes) 1777 13 b 3 java.lang.CharacterData::of (120 bytes) 1785 14 b 3 java.lang.CharacterDataLatin1::getProperties (11 bytes) 1817 15 b 3 java.lang.String:: (67 bytes) 1839 16 b 3 java.lang.String::getChars (62 bytes) 1852 17 b 3 java.lang.AbstractStringBuilder::append (48 bytes) 1868 18 b 3 java.lang.Character::toUpperCaseEx (30 bytes) ... 530728 2660 b 4 java.util.IdentityHashMap::hash (18 bytes) 530733 1183 3 java.util.IdentityHashMap::hash (18 bytes) made not entrant 530734 2259 3 org.jruby.RubyObject$1::allocate (10 bytes) made zombie 530735 2265 3 org.jruby.runtime.callsite.CachingCallSite::call (50 bytes) made zombie 566829 2661 b 4 java.lang.invoke.LambdaForm$MH/1997160570::guard (80 bytes) 567198 2651 3 java.lang.invoke.LambdaForm$MH/1997160570::guard (80 bytes) made not entrant 567201 2280 3 org.jruby.ast.executable.AbstractScript::setVariable2 (12 bytes) made zombie 567201 2279 3 org.jruby.ast.executable.AbstractScript::setVariable3 (12 bytes) made zombie 567201 2277 3 org.jruby.ast.executable.AbstractScript::setVariable1 (12 bytes) made zombie 567201 2276 3 org.jruby.ast.executable.AbstractScript::setVariable0 (12 bytes) made zombie 567206 2662 b 4 java.lang.invoke.LambdaForm$MH/2083201325::guard (86 bytes) 567501 2652 3 java.lang.invoke.LambdaForm$MH/2083201325::guard (86 bytes) made not entrant 969865 2663 b 1 java.util.Hashtable::access$600 (5 bytes) 970025 2278 3 org.jruby.ast.executable.AbstractScript::setVariable4 (12 bytes) made zombie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120711/4b4eccea/attachment-0001.html From headius at headius.com Wed Jul 11 14:12:36 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 11 Jul 2012 14:12:36 -0700 Subject: Testing out latest work In-Reply-To: References: Message-ID: On Wed, Jul 11, 2012 at 1:46 PM, John Rose wrote: > Thanks for testing. Sorry it didn't get so far! I think we have a depot > bug and/or race condition. It may be that more cores make the bug happen > more. Oh yes, I should explain the system I'm on, in case it's relevant... OS X Lion, newish MBP, 4-core, 16GB memory. fib fails consistently in a variety of ways...NullPointer, ArrayIndex, ClassCast. Here's a few more traces: https://gist.github.com/4f72d09d0bb945801211 > I am able to grind through things like bench/bench_red_black.rb in several > modes, such as [1]. Yes, it is slow, so something is out of tune. We are > going for correctness at the moment. Indeed...I don't expect to see performance at this point. I was just hoping to get JRuby green on the new work, and running these few benchmarks were my sanity test before I proceeded with that. red_black is a good benchmark, as are richards and neural. fib, tak, and base64 are nice simple numeric benchmarks. I was also able to run red_black for some time with your command line, but the same command line failed to run fib successfully. Recursion? Deep stacks? Happy to try anything or provide dumps or log output. My fib command line is generally: jruby bench/bench_fib_recursive.rb 10 35 - Charlie From john.r.rose at oracle.com Wed Jul 11 14:17:16 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 11 Jul 2012 14:17:16 -0700 Subject: Testing out latest work In-Reply-To: References: Message-ID: <42A3E41A-D079-4796-94B8-1BB96AAB8B47@oracle.com> On Jul 11, 2012, at 2:12 PM, Charles Oliver Nutter wrote: > OS X Lion, newish MBP, 4-core, 16GB memory. I have a 2009 MBP with 2 cores. We have a creeping suspicion that the crashing is more common on the 4-core machines. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120711/8fe32a3b/attachment.html From vladimir.kozlov at oracle.com Wed Jul 11 14:35:19 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 Jul 2012 14:35:19 -0700 Subject: review request (M): 6711908: JVM needs direct access to some annotations In-Reply-To: References: Message-ID: <4FFDF197.8090304@oracle.com> c1_GraphBuilder.cpp, can you remove setting bailout message for forced inlining? It should be done proper uniform way for C1 inlining later. I think, next assert should check (id >= _unknown && id < _annotation_LIMIT) instead: + void set_annotation(ID id) { + assert((int)id > 0 && (int)id < BitsPerInt, "oob"); In header file classFileParser.hpp you should not specify ClassFileParser:: in method parse_classfile_attributes(() declaration: ClassFileParser::ClassAnnotationCollector* parsed_annotations Instead of asserts in apply_to() methods we should use guarantee("not implemented") or something. I don't think next should be part of these changes: +#if 0 + // The parsing of @Retention is for example only. Add parenthesis around expression in next condition: + while (--nann >= 0 && index-2 + min_size <= limit) { Instead of passing pointers to classFileParser's new attributes fields (_synthetic_flag, _sourcefile, ...) as arguments add accessors functions which set these fields. I think next is typo, should be _in_method check: + case vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): + if (_location != _in_class) break; + return _method_ForceInline; + default: break; + } Thanks, Vladimir John Rose wrote: > This is a building block for an upcoming large enhancement for method handles. > > http://cr.openjdk.java.net/~jrose/6711908/webrev.00 > > The implemented interface is completely private to the java.lang.invoke package. > > ? John From christian.thalinger at oracle.com Wed Jul 11 14:42:42 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 Jul 2012 14:42:42 -0700 Subject: Testing out latest work In-Reply-To: <42A3E41A-D079-4796-94B8-1BB96AAB8B47@oracle.com> References: <42A3E41A-D079-4796-94B8-1BB96AAB8B47@oracle.com> Message-ID: On Jul 11, 2012, at 2:17 PM, John Rose wrote: > On Jul 11, 2012, at 2:12 PM, Charles Oliver Nutter wrote: > >> OS X Lion, newish MBP, 4-core, 16GB memory. > > I have a 2009 MBP with 2 cores. We have a creeping suspicion that the crashing is more common on the 4-core machines. I just fixed a problem that explains a lot of these intermittent failures (which I'm about to push after some sanity testing). And Charlie applied the xbmh patch which might explain some of the performance problems (just a wild guess). -- Chris > > ? John > _______________________________________________ > 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/20120711/a378dbb9/attachment.html From forax at univ-mlv.fr Wed Jul 11 15:05:39 2012 From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=) Date: Thu, 12 Jul 2012 00:05:39 +0200 Subject: hg: mlvm/mlvm/jdk: meth: add @Hidden annotations In-Reply-To: References: <20120711061912.00D6A47F4E@hg.openjdk.java.net> <4FFD476A.6010404@univ-mlv.fr> Message-ID: <4FFDF8B3.9060108@univ-mlv.fr> On 07/11/2012 10:24 PM, John Rose wrote: > On Jul 11, 2012, at 2:29 AM, R?mi Forax wrote: > >> just a question, even if it's not a big deal if one is able to generate >> bytecode, >> why Hidden is not a top level type of java.lang.invoke ? > > Good question. The answer is that hiding of stack frames is limited to > hiding method handle implementation details. Specifically, the frames > that are to be hidden are those which are not specified by the JSR 292 > modifications to the JVMS. > > For example, if you have z=filterReturnValue(::x,::y), and some method > m does z.invoke(), the visible stack frames will be m calling x and m > calling y. Internally there will be a continuation during the call to > x which waits to apply y. This must be some sort of activation frame, > but the JVMS requires it to be hidden. In JDK 7 it was a ricochet > frame (hand assembly code) and in JDK 8 it will be a lambda form > activation (bytecode). Both must be suppressed in backtraces. > > A general Lisp-machine-style convention for redacting back traces > would be interesting, but it would also require a new JSR. > > On the other hand, Hidden could be top-level. It's a matter of coding > taste. Binding it to LF makes it more clear that it has a specific use. Emulating a language call using bytecode is something that should ring a bell for a lot of people of this list :) And even for the JDK, it by example generates bytecode when optimizing a call to j.l.r.Method and this bytecode should not appear in the stacktrace. > > ? John R?mi From headius at headius.com Wed Jul 11 15:04:43 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 11 Jul 2012 15:04:43 -0700 Subject: Testing out latest work In-Reply-To: References: <42A3E41A-D079-4796-94B8-1BB96AAB8B47@oracle.com> Message-ID: On Wed, Jul 11, 2012 at 2:42 PM, Christian Thalinger wrote: > I just fixed a problem that explains a lot of these intermittent failures > (which I'm about to push after some sanity testing). And Charlie applied > the xbmh patch which might explain some of the performance problems (just a > wild guess). Still waiting on Christian's additional patch, but removing xbmh did not appear to help anything. Rebuilt, ran fib, and... system ~/projects/jruby $ jruby bench/bench_fib_recursive.rb 10 35 LambdaForm$BMH:-1:in `reinvoke': java.lang.ClassCastException: org.jruby.MetaClass cannot be cast to java.lang.invoke.BoundMethodHandle$Multiple from LambdaForm$DMH:-1:in `invokeStatic' from LambdaForm$BMH:-1:in `reinvoke' from LambdaForm$MH:-1:in `guard' from LambdaForm$DMH:-1:in `invokeSpecial' from LambdaForm$MH:-1:in `guard' from LambdaForm$MH:-1:in `linkToCallSite' None of these exceptions really make sense. - Charlie From michael.haupt at oracle.com Wed Jul 11 15:10:45 2012 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 12 Jul 2012 00:10:45 +0200 Subject: hg: mlvm/mlvm/jdk: meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding In-Reply-To: <4FFDE6A6.2020504@univ-mlv.fr> References: <20120711200740.DA60847F94@hg.openjdk.java.net> <4FFDE6A6.2020504@univ-mlv.fr> Message-ID: Hi Remy, Am 11.07.2012 um 22:48 schrieb R?mi Forax: > Hi Mickael, > some minor comments, > makeSignature should use a StringBuilder and not a StringBuffer. good point, thanks! > ans I don't think generateConcreteBMHClass needs to return a Class extends BoundMethodHandle>, > a Class seems enough so the cast near the end of the method can be > removed. I'd like to keep that to make really clear what Class type instances are expected. (There are places where Class would just feel very wrong.) Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120712/04947ada/attachment-0001.html From forax at univ-mlv.fr Wed Jul 11 15:26:15 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 12 Jul 2012 00:26:15 +0200 Subject: hg: mlvm/mlvm/jdk: meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding In-Reply-To: References: <20120711200740.DA60847F94@hg.openjdk.java.net> <4FFDE6A6.2020504@univ-mlv.fr> Message-ID: <4FFDFD87.1050808@univ-mlv.fr> On 07/12/2012 12:10 AM, Michael Haupt wrote: > Hi Remy, > > Am 11.07.2012 um 22:48 schrieb R?mi Forax: >> Hi Mickael, >> some minor comments, >> makeSignature should use a StringBuilder and not a StringBuffer. > > good point, thanks! > >> ans I don't think generateConcreteBMHClass needs to return a Class> extends BoundMethodHandle>, >> a Class seems enough so the cast near the end of the method can be >> removed. > > I'd like to keep that to make really clear what Class type instances > are expected. > (There are places where Class would just feel very wrong.) but the cast seems wrong to me because this one is not enforced by the VM so if there is a bug, you may lure the reader of the code. I think a doc comment is better here. Or perhaps you can use asSubClass() ? > > Best, > > Michael regards, R?mi From christian.thalinger at oracle.com Wed Jul 11 15:32:20 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 11 Jul 2012 22:32:20 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: fix for intermittent exceptions of various kinds and crashes Message-ID: <20120711223220.78C7E47F96@hg.openjdk.java.net> Changeset: 22a0e2e50ec4 Author: twisti Date: 2012-07-11 15:32 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/22a0e2e50ec4 meth-lazy: fix for intermittent exceptions of various kinds and crashes ! meth-lazy-7023639.patch From john.r.rose at oracle.com Wed Jul 11 15:47:43 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 11 Jul 2012 15:47:43 -0700 Subject: review request (M): 6711908: JVM needs direct access to some annotations In-Reply-To: <4FFDF197.8090304@oracle.com> References: <4FFDF197.8090304@oracle.com> Message-ID: <7B24C2EE-EB57-41D0-B65D-25BCBA83F565@oracle.com> On Jul 11, 2012, at 12:01 AM, Michael Haupt wrote: > @@ -1636,16 +1648,163 @@ > The code for parsing @Retention deserves a comment highlighting that it is about parsing an annotation with payload (none of the annotations introduced by our work do this). > > @@ -2560,10 +2727,11 @@ > TempNewSymbol sde_symbol is never used. Fixed; thanks. On Jul 11, 2012, at 2:35 PM, Vladimir Kozlov wrote: > c1_GraphBuilder.cpp, can you remove setting bailout message for forced inlining? It should be done proper uniform way for C1 inlining later. Done. > I think, next assert should check (id >= _unknown && id < _annotation_LIMIT) instead: > > + void set_annotation(ID id) { > + assert((int)id > 0 && (int)id < BitsPerInt, "oob"); Good. I added this to the constructor assert((int)_annotation_LIMIT <= (int)sizeof(_annotations_present) * BitsPerByte, ""); > In header file classFileParser.hpp you should not specify ClassFileParser:: in method parse_classfile_attributes(() declaration: > > ClassFileParser::ClassAnnotationCollector* parsed_annotations Good catch. > Instead of asserts in apply_to() methods we should use guarantee("not implemented") or something. Done: + guarantee(false, "no field annotations yet"); > > I don't think next should be part of these changes: > > +#if 0 > + // The parsing of @Retention is for example only. Yes, Michael asked about that too. The point is to show how annotation payloads can be processed. Somebody will need it at some point. I'll make it into a comment; is that OK? + // For the record, here is how annotation payloads can be collected. + // Suppose we want to capture @Retention.value. Here is how: + //if (id == AnnotationCollector::_class_Retention) { > Add parenthesis around expression in next condition: > > + while (--nann >= 0 && index-2 + min_size <= limit) { Done: + while ((--nann) >= 0 && (index-2 + min_size <= limit)) { > Instead of passing pointers to classFileParser's new attributes fields (_synthetic_flag, _sourcefile, ...) as arguments add accessors functions which set these fields. The pointer passing is following the pattern already present for parsing other constructs. parse_fields is the clearest example. The parsed information is returned by reference. I could do as you suggest, but it would work only for top-level class attributes, so there would still be a mix of styles. My thought is to make the style more uniform by relying on the return-by-reference pattern. But I'll change it if you insist. > I think next is typo, should be _in_method check: > > + case vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): > + if (_location != _in_class) break; > + return _method_ForceInline; > + default: break; > + } Yes; thanks. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120711/742326f9/attachment.html From michael.haupt at oracle.com Wed Jul 11 15:48:18 2012 From: michael.haupt at oracle.com (michael.haupt at oracle.com) Date: Wed, 11 Jul 2012 22:48:18 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: refactorings, made test more stressful Message-ID: <20120711224818.E046347F97@hg.openjdk.java.net> Changeset: 0a120a3124fe Author: mhaupt Date: 2012-07-12 00:47 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/0a120a3124fe meth-lazy: refactorings, made test more stressful ! meth-lazy-7023639.xbmh.patch From michael.haupt at oracle.com Wed Jul 11 15:48:34 2012 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 12 Jul 2012 00:48:34 +0200 Subject: hg: mlvm/mlvm/jdk: meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding In-Reply-To: <4FFDFD87.1050808@univ-mlv.fr> References: <20120711200740.DA60847F94@hg.openjdk.java.net> <4FFDE6A6.2020504@univ-mlv.fr> <4FFDFD87.1050808@univ-mlv.fr> Message-ID: <76C0359A-85D8-441E-804E-1F531EE4193D@oracle.com> Hi, Am 12.07.2012 um 00:26 schrieb R?mi Forax: > Or perhaps you can use asSubClass() ? asSubclass() it is. :-) Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120712/983dd000/attachment.html From john.r.rose at oracle.com Wed Jul 11 17:17:55 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 12 Jul 2012 00:17:55 +0000 Subject: hg: mlvm/mlvm/hotspot: annot: incorporate review comments Message-ID: <20120712001756.2167847FA3@hg.openjdk.java.net> Changeset: 34aa8c19bcaa Author: jrose Date: 2012-07-11 17:17 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/34aa8c19bcaa annot: incorporate review comments ! annot-6711908.patch From john.r.rose at oracle.com Wed Jul 11 17:18:29 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 12 Jul 2012 00:18:29 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: fix register crush on x86_32, rebase for annot Message-ID: <20120712001830.09F6947FA4@hg.openjdk.java.net> Changeset: a3668184eaae Author: jrose Date: 2012-07-11 17:18 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a3668184eaae meth: fix register crush on x86_32, rebase for annot ! meth-lazy-7023639.patch From vladimir.kozlov at oracle.com Wed Jul 11 17:25:46 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 11 Jul 2012 17:25:46 -0700 Subject: review request (M): 6711908: JVM needs direct access to some annotations In-Reply-To: <7B24C2EE-EB57-41D0-B65D-25BCBA83F565@oracle.com> References: <4FFDF197.8090304@oracle.com> <7B24C2EE-EB57-41D0-B65D-25BCBA83F565@oracle.com> Message-ID: <4FFE198A.4050901@oracle.com> > Yes, Michael asked about that too. The point is to show how annotation > payloads can be processed. Somebody will need it at some point. I'll > make it into a comment; is that OK? OK. >> Instead of passing pointers to classFileParser's new attributes fields >> (_synthetic_flag, _sourcefile, ...) as arguments add accessors >> functions which set these fields. > > The pointer passing is following the pattern already present for parsing > other constructs. parse_fields is the clearest example. The parsed > information is returned by reference. I could do as you suggest, but it For parse_fields() references for local variables are passed. It is different from passing references to classFileParser's fields which are accessible inside methods. > would work only for top-level class attributes, so there would still be > a mix of styles. My thought is to make the style more uniform by > relying on the return-by-reference pattern. > > But I'll change it if you insist. Please, change. Also put final klass settings "Fill in field values from parse_classfile_attributes" in a separate ClassFileParser method. Thanks, Vladimir John Rose wrote: > On Jul 11, 2012, at 12:01 AM, Michael Haupt wrote: > >> @@ -1636,16 +1648,163 @@ >> The code for parsing @Retention deserves a comment highlighting that >> it is about parsing an annotation with payload (none of the >> annotations introduced by our work do this). >> >> @@ -2560,10 +2727,11 @@ >> TempNewSymbol sde_symbol is never used. > > Fixed; thanks. > > > On Jul 11, 2012, at 2:35 PM, Vladimir Kozlov wrote: > >> c1_GraphBuilder.cpp, can you remove setting bailout message for forced >> inlining? It should be done proper uniform way for C1 inlining later. > > Done. > >> I think, next assert should check (id >= _unknown && id < >> _annotation_LIMIT) instead: >> >> + void set_annotation(ID id) { >> + assert((int)id > 0 && (int)id < BitsPerInt, "oob"); > > Good. I added this to the constructor > assert((int)_annotation_LIMIT <= (int)sizeof(_annotations_present) * > BitsPerByte, ""); > >> In header file classFileParser.hpp you should not specify >> ClassFileParser:: in method parse_classfile_attributes(() declaration: >> >> ClassFileParser::ClassAnnotationCollector* parsed_annotations > > Good catch. > >> Instead of asserts in apply_to() methods we should use guarantee("not >> implemented") or something. > > Done: > + guarantee(false, "no field annotations yet"); > >> >> I don't think next should be part of these changes: >> >> +#if 0 >> + // The parsing of @Retention is for example only. > > Yes, Michael asked about that too. The point is to show how annotation > payloads can be processed. Somebody will need it at some point. I'll > make it into a comment; is that OK? > + // For the record, here is how annotation payloads can be collected. > + // Suppose we want to capture @Retention.value. Here is how: > + //if (id == AnnotationCollector::_class_Retention) { > >> Add parenthesis around expression in next condition: >> >> + while (--nann >= 0 && index-2 + min_size <= limit) { > > Done: > + while ((--nann) >= 0 && (index-2 + min_size <= limit)) { > >> Instead of passing pointers to classFileParser's new attributes fields >> (_synthetic_flag, _sourcefile, ...) as arguments add accessors >> functions which set these fields. > > The pointer passing is following the pattern already present for parsing > other constructs. parse_fields is the clearest example. The parsed > information is returned by reference. I could do as you suggest, but it > would work only for top-level class attributes, so there would still be > a mix of styles. My thought is to make the style more uniform by > relying on the return-by-reference pattern. > > But I'll change it if you insist. > >> I think next is typo, should be _in_method check: >> >> + case >> vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): >> + if (_location != _in_class) break; >> + return _method_ForceInline; >> + default: break; >> + } > > Yes; thanks. > > ? John From john.r.rose at oracle.com Wed Jul 11 17:29:38 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 12 Jul 2012 00:29:38 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: transfer last asm change to sparc Message-ID: <20120712002939.1864947FA5@hg.openjdk.java.net> Changeset: c748a6624c8b Author: jrose Date: 2012-07-11 17:29 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c748a6624c8b meth: transfer last asm change to sparc ! meth-lazy-7023639.patch From stephen.bannasch at deanbrook.org Wed Jul 11 17:46:27 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 11 Jul 2012 20:46:27 -0400 Subject: OSX port In-Reply-To: <7E880DC4-40F2-4715-8A81-DEDDA52C5C12@iq80.com> References: <06E1B1D8-8C6A-409B-BB2C-0313A4765613@gmail.com> <30DB491D-6A1B-41D9-B57C-A629716D7E1C@oracle.com> <7E880DC4-40F2-4715-8A81-DEDDA52C5C12@iq80.com> Message-ID: At 10:26 AM -0700 7/11/12, Dain Sundstrom wrote: >Does this build contain the coro patch? > >-dain > >On Jul 11, 2012, at 9:27 AM, Stephen Bannasch wrote: > >> Hi Henri >> >> By setting ALT_BOOTDIR and ALT_JDK_IMPORT_PATH to use a recent Java 1.8 build (from last week, 2012_07_07) my mlvm now compiles >> and runs fine on 10.6.8 >> >> Updated script here: https://gist.github.com/243072 >> >> Am running following jtreg tests: >> >> jdk/test/java/lang/invoke/ > > jdk/test/java/dyn/CoroutineTest.java I would think so since I am successfully running the Couroutine tests ;-) From john.r.rose at oracle.com Wed Jul 11 17:49:35 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 11 Jul 2012 17:49:35 -0700 Subject: review request (M): 6711908: JVM needs direct access to some annotations In-Reply-To: <4FFE198A.4050901@oracle.com> References: <4FFDF197.8090304@oracle.com> <7B24C2EE-EB57-41D0-B65D-25BCBA83F565@oracle.com> <4FFE198A.4050901@oracle.com> Message-ID: On Jul 11, 2012, at 5:25 PM, Vladimir Kozlov wrote: > > would work only for top-level class attributes, so there would still be > > a mix of styles. My thought is to make the style more uniform by > > relying on the return-by-reference pattern. > > > > But I'll change it if you insist. > > Please, change. Also put final klass settings "Fill in field values from parse_classfile_attributes" in a separate ClassFileParser method. OK, will do. :-) ? John P.S. That was just the warmup. Here comes the big change set... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120711/2cb72c20/attachment.html From john.r.rose at oracle.com Wed Jul 11 17:53:58 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 11 Jul 2012 17:53:58 -0700 Subject: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code Message-ID: As some of you have noticed, Chris Thalinger, Michael Haupt, and I have been working on the mlvm patches [1] for JEP-160 [2] for several months. These changes make method handles more optimizable. They refactor lots of "magic" out of the JVM and into more manageable Java code. To get an idea of how much "magic" is being removed, consider that the change removes 12,000 lines of non-comment code from the JVM, including much assembly code. It inserts 4900 lines of non-comment code. These changes are now stable enough to integrate. They pass jtreg tests in a number of execution modes and platforms. They also correctly run various JRuby and Nashorn test programs. Although there are no performance gains to boast about at present, these changes clear the ground for long-term optimization work. Here is the webrev [3], for review and integration into JDK 8 via hotspot-comp/hotspot/. Because of the large size of this change set, we request that reviewers would clearly designate which files they are reviewing. That way we may be able to divide up the work a little more effectively. Also, because of the scope of the change, we may respond to some comments by promising to address an issue in a future change set. If necessary, we will file tracking bugs to make sure nothing gets dropped. We have been working on this for months, and expect to make many further changes. The immediate need to get the changes in is twofold: First, some bugs (involving symbolic references off the boot class path) require the new Lambda Form intermediate representation, which is "off-BCP-clean". Second, we need to commit our pervasive changes to the JVM sooner rather than later, so they can be properly integrated with other pervasive changes, such as metadata changes. An associated webrev for hotspot-comp/jdk/ will be posted soon; it is already present on mlvm-dev for the curious to examine. (This change set also deletes a lot of old code.) Thanks in advance, ? John [1] http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy-7023639.patch [2] http://openjdk.java.net/jeps/160 [3] http://cr.openjdk.java.net/~jrose/7023639/webrev.00/ From christian.thalinger at oracle.com Wed Jul 11 18:40:42 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 Jul 2012 18:40:42 -0700 Subject: review request (M): 6711908: JVM needs direct access to some annotations In-Reply-To: <4FFDF197.8090304@oracle.com> References: <4FFDF197.8090304@oracle.com> Message-ID: On Jul 11, 2012, at 2:35 PM, Vladimir Kozlov wrote: > c1_GraphBuilder.cpp, can you remove setting bailout message for forced inlining? It should be done proper uniform way for C1 inlining later. In the final version (a couple patches later) it looks like this: // now perform tests that are based on flag settings if (callee->force_inline() || callee->should_inline()) { // ignore heuristic controls on inlining print_inlining(callee, "force inline by annotation"); -- Chris > > I think, next assert should check (id >= _unknown && id < _annotation_LIMIT) instead: > > + void set_annotation(ID id) { > + assert((int)id > 0 && (int)id < BitsPerInt, "oob"); > > > In header file classFileParser.hpp you should not specify ClassFileParser:: in method parse_classfile_attributes(() declaration: > > ClassFileParser::ClassAnnotationCollector* parsed_annotations > > > Instead of asserts in apply_to() methods we should use guarantee("not implemented") or something. > > > I don't think next should be part of these changes: > > +#if 0 > + // The parsing of @Retention is for example only. > > > Add parenthesis around expression in next condition: > > + while (--nann >= 0 && index-2 + min_size <= limit) { > > > Instead of passing pointers to classFileParser's new attributes fields (_synthetic_flag, _sourcefile, ...) as arguments add accessors functions which set these fields. > > > I think next is typo, should be _in_method check: > > + case vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): > + if (_location != _in_class) break; > + return _method_ForceInline; > + default: break; > + } > > Thanks, > Vladimir > > John Rose wrote: >> This is a building block for an upcoming large enhancement for method handles. >> http://cr.openjdk.java.net/~jrose/6711908/webrev.00 >> The implemented interface is completely private to the java.lang.invoke package. >> ? John From christian.thalinger at oracle.com Wed Jul 11 18:41:47 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 11 Jul 2012 18:41:47 -0700 Subject: review request (M): 6711908: JVM needs direct access to some annotations In-Reply-To: <7B24C2EE-EB57-41D0-B65D-25BCBA83F565@oracle.com> References: <4FFDF197.8090304@oracle.com> <7B24C2EE-EB57-41D0-B65D-25BCBA83F565@oracle.com> Message-ID: <44D23D58-EFAD-4DE3-8355-5664E3080082@oracle.com> On Jul 11, 2012, at 3:47 PM, John Rose wrote: > On Jul 11, 2012, at 12:01 AM, Michael Haupt wrote: > >> @@ -1636,16 +1648,163 @@ >> The code for parsing @Retention deserves a comment highlighting that it is about parsing an annotation with payload (none of the annotations introduced by our work do this). >> >> @@ -2560,10 +2727,11 @@ >> TempNewSymbol sde_symbol is never used. > > Fixed; thanks. > > > On Jul 11, 2012, at 2:35 PM, Vladimir Kozlov wrote: > >> c1_GraphBuilder.cpp, can you remove setting bailout message for forced inlining? It should be done proper uniform way for C1 inlining later. > > Done. > >> I think, next assert should check (id >= _unknown && id < _annotation_LIMIT) instead: >> >> + void set_annotation(ID id) { >> + assert((int)id > 0 && (int)id < BitsPerInt, "oob"); > > Good. I added this to the constructor > assert((int)_annotation_LIMIT <= (int)sizeof(_annotations_present) * BitsPerByte, ""); > >> In header file classFileParser.hpp you should not specify ClassFileParser:: in method parse_classfile_attributes(() declaration: >> >> ClassFileParser::ClassAnnotationCollector* parsed_annotations > > Good catch. > >> Instead of asserts in apply_to() methods we should use guarantee("not implemented") or something. > > Done: > + guarantee(false, "no field annotations yet"); fatal would be the right one; it doesn't take a boolean. -- Chris > >> >> I don't think next should be part of these changes: >> >> +#if 0 >> + // The parsing of @Retention is for example only. > > Yes, Michael asked about that too. The point is to show how annotation payloads can be processed. Somebody will need it at some point. I'll make it into a comment; is that OK? > + // For the record, here is how annotation payloads can be collected. > + // Suppose we want to capture @Retention.value. Here is how: > + //if (id == AnnotationCollector::_class_Retention) { > >> Add parenthesis around expression in next condition: >> >> + while (--nann >= 0 && index-2 + min_size <= limit) { > > Done: > + while ((--nann) >= 0 && (index-2 + min_size <= limit)) { > >> Instead of passing pointers to classFileParser's new attributes fields (_synthetic_flag, _sourcefile, ...) as arguments add accessors functions which set these fields. > > The pointer passing is following the pattern already present for parsing other constructs. parse_fields is the clearest example. The parsed information is returned by reference. I could do as you suggest, but it would work only for top-level class attributes, so there would still be a mix of styles. My thought is to make the style more uniform by relying on the return-by-reference pattern. > > But I'll change it if you insist. > >> I think next is typo, should be _in_method check: >> >> + case vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature): >> + if (_location != _in_class) break; >> + return _method_ForceInline; >> + default: break; >> + } > > Yes; thanks. > > ? John > _______________________________________________ > 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/20120711/cbd9297c/attachment-0001.html From headius at headius.com Wed Jul 11 22:47:24 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 11 Jul 2012 22:47:24 -0700 Subject: Testing out latest work In-Reply-To: References: <42A3E41A-D079-4796-94B8-1BB96AAB8B47@oracle.com> Message-ID: Updates! On Wed, Jul 11, 2012 at 3:04 PM, Charles Oliver Nutter wrote: > Still waiting on Christian's additional patch, but removing xbmh did > not appear to help anything. Rebuilt, ran fib, and... I pulled down all updates from today, did a fresh build, and things appear to be working properly. Hooray! Perf isn't at u4 levels, but it isn't awful and stability seems pretty good...even including a few command lines that always triggered the dreaded NCDFE. Wonderful! Tomorrow I'll look at getting JRuby's "jit immediately" and AOT test runs green so we can start to use that as a sanity test for the new indy logic. - Charlie From michael.haupt at oracle.com Wed Jul 11 23:13:08 2012 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 12 Jul 2012 08:13:08 +0200 Subject: Testing out latest work In-Reply-To: References: <42A3E41A-D079-4796-94B8-1BB96AAB8B47@oracle.com> Message-ID: Charles, Am 12.07.2012 um 07:47 schrieb Charles Oliver Nutter: > I pulled down all updates from today, did a fresh build, and things > appear to be working properly. Hooray! :-) > Perf isn't at u4 levels, but it isn't awful and stability seems pretty > good...even including a few command lines that always triggered the > dreaded NCDFE. Wonderful! Can you say some more about the performance? How much slower is it? Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120712/448bf187/attachment.html From john.r.rose at oracle.com Wed Jul 11 23:33:29 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 12 Jul 2012 06:33:29 +0000 Subject: hg: mlvm/mlvm/hotspot: annot: update for review comments Message-ID: <20120712063330.12CB347FAB@hg.openjdk.java.net> Changeset: 7b29f3a51eea Author: jrose Date: 2012-07-11 23:33 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/7b29f3a51eea annot: update for review comments ! annot-6711908.patch From john.r.rose at oracle.com Wed Jul 11 23:40:08 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 11 Jul 2012 23:40:08 -0700 Subject: Testing out latest work In-Reply-To: References: <42A3E41A-D079-4796-94B8-1BB96AAB8B47@oracle.com> Message-ID: <3871A973-1F04-464E-AA57-65760A3019AC@oracle.com> On Jul 11, 2012, at 10:47 PM, Charles Oliver Nutter wrote: > I pulled down all updates from today, did a fresh build, and things > appear to be working properly. Hooray! Hooray indeed! Now we are on the right track. Thanks (again) for joining us on the bleeding edge. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120711/af6b3f30/attachment.html From headius at headius.com Wed Jul 11 23:44:38 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 11 Jul 2012 23:44:38 -0700 Subject: Testing out latest work In-Reply-To: References: <42A3E41A-D079-4796-94B8-1BB96AAB8B47@oracle.com> Message-ID: On Wed, Jul 11, 2012 at 11:13 PM, Michael Haupt wrote: > Can you say some more about the performance? How much slower is it? It ranges...fib is around 80% slower. Richards is like 150% slower. red_black is a bit slower than that. We're not talking orders of magnitude, but they're kinda where we were this time last year before we really go to tuning. After I look into the test suites, I'll start comparing assembly dumps for the simpler bits so we can get a better idea what's not optimizing as well. - Charlie From john.r.rose at oracle.com Wed Jul 11 23:54:22 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 11 Jul 2012 23:54:22 -0700 Subject: review request (M): 6711908: JVM needs direct access to some annotations In-Reply-To: <4FFE198A.4050901@oracle.com> References: <4FFDF197.8090304@oracle.com> <7B24C2EE-EB57-41D0-B65D-25BCBA83F565@oracle.com> <4FFE198A.4050901@oracle.com> Message-ID: <29805C39-CF19-434B-8A65-7443E84CEE1F@oracle.com> On Jul 11, 2012, at 5:25 PM, Vladimir Kozlov wrote: > > But I'll change it if you insist. > > Please, change. Also put final klass settings "Fill in field values from parse_classfile_attributes" in a separate ClassFileParser method. Done. Here is the updated webrev: http://cr.openjdk.java.net/~jrose/6711908/webrev.01 (See synopsis below.) ? John @@ -62,6 +64,22 @@ typeArrayHandle _inner_classes; typeArrayHandle _annotations; + void set_class_synthetic_flag(bool x) { _synthetic_flag = x; } + void set_class_sourcefile(Symbol* x) { _sourcefile = x; } + void set_class_generic_signature(Symbol* x) { _generic_signature = x; } + void set_class_sde_symbol(Symbol* x) { _sde_symbol = x; } + void set_class_inner_classes(typeArrayHandle x) { _inner_classes = x; } + void set_class_annotations(typeArrayHandle x) { _annotations = x; } + void init_parsed_class_attributes() { + _synthetic_flag = false; + _sourcefile = NULL; + _generic_signature = NULL; + // initialize the other flags too: + _has_finalizer = _has_empty_finalizer = _has_vanilla_constructor = false; + _max_bootstrap_specifier_index = -1; + } + void apply_parsed_class_attributes(instanceKlassHandle k); // update k + class AnnotationCollector { public: enum Location { _in_field, _in_method, _in_class }; @@ -2866,6 +2863,21 @@ } } +void ClassFileParser::apply_parsed_class_attributes(instanceKlassHandle k) { + if (_synthetic_flag) + k->set_is_synthetic(); + if (_sourcefile != NULL) { + _sourcefile->increment_refcount(); + k->set_source_file_name(_sourcefile); + } + if (_generic_signature != NULL) { + _generic_signature->increment_refcount(); + k->set_generic_signature(_generic_signature); + } + k->set_source_debug_extension(_sde_symbol); // increment_refcount inside + k->set_inner_classes(_inner_classes()); + k->set_class_annotations(_annotations()); +} typeArrayHandle ClassFileParser::assemble_annotations(u1* runtime_visible_annotations, int runtime_visible_annotations_length, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120711/d39db1e1/attachment.html From michael.haupt at oracle.com Thu Jul 12 00:18:43 2012 From: michael.haupt at oracle.com (Michael Haupt) Date: Thu, 12 Jul 2012 09:18:43 +0200 Subject: Testing out latest work In-Reply-To: References: <42A3E41A-D079-4796-94B8-1BB96AAB8B47@oracle.com> Message-ID: Charles, Am 12.07.2012 um 08:44 schrieb Charles Oliver Nutter: > It ranges...fib is around 80% slower. Richards is like 150% slower. > red_black is a bit slower than that. We're not talking orders of > magnitude, but they're kinda where we were this time last year before > we really go to tuning. After I look into the test suites, I'll start > comparing assembly dumps for the simpler bits so we can get a better > idea what's not optimizing as well. good. Note that the tuning is up next. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120712/e527a433/attachment-0001.html From john.r.rose at oracle.com Thu Jul 12 00:37:50 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 12 Jul 2012 07:37:50 +0000 Subject: hg: mlvm/mlvm/hotspot: annot: update for review comments Message-ID: <20120712073750.39EB147FAF@hg.openjdk.java.net> Changeset: 0ffb542eb0de Author: jrose Date: 2012-07-12 00:37 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/0ffb542eb0de annot: update for review comments ! annot-6711908.patch From john.r.rose at oracle.com Thu Jul 12 00:50:51 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 12 Jul 2012 07:50:51 +0000 Subject: hg: mlvm/mlvm/hotspot: annot, meth: update Message-ID: <20120712075051.EB19E47FB0@hg.openjdk.java.net> Changeset: 71016edd5799 Author: jrose Date: 2012-07-12 00:50 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/71016edd5799 annot, meth: update ! annot-6711908.patch ! meth-lazy-7023639.patch From vladimir.kozlov at oracle.com Thu Jul 12 01:08:35 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Jul 2012 01:08:35 -0700 Subject: review request (M): 6711908: JVM needs direct access to some annotations In-Reply-To: <29805C39-CF19-434B-8A65-7443E84CEE1F@oracle.com> References: <4FFDF197.8090304@oracle.com> <7B24C2EE-EB57-41D0-B65D-25BCBA83F565@oracle.com> <4FFE198A.4050901@oracle.com> <29805C39-CF19-434B-8A65-7443E84CEE1F@oracle.com> Message-ID: <4FFE8603.5010702@oracle.com> This looks good. Thanks, Vladimir On 7/11/12 11:54 PM, John Rose wrote: > On Jul 11, 2012, at 5:25 PM, Vladimir Kozlov wrote: > >> > But I'll change it if you insist. >> >> Please, change. Also put final klass settings "Fill in field values from parse_classfile_attributes" in a separate >> ClassFileParser method. > > Done. Here is the updated webrev: > http://cr.openjdk.java.net/~jrose/6711908/webrev.01 > > (See synopsis below.) > > ? John > > > @@ -62,6 +64,22 @@ > typeArrayHandle _inner_classes; > typeArrayHandle _annotations; > + void set_class_synthetic_flag(bool x) { _synthetic_flag = x; } > + void set_class_sourcefile(Symbol* x) { _sourcefile = x; } > + void set_class_generic_signature(Symbol* x) { _generic_signature = x; } > + void set_class_sde_symbol(Symbol* x) { _sde_symbol = x; } > + void set_class_inner_classes(typeArrayHandle x) { _inner_classes = x; } > + void set_class_annotations(typeArrayHandle x) { _annotations = x; } > + void init_parsed_class_attributes() { > + _synthetic_flag = false; > + _sourcefile = NULL; > + _generic_signature = NULL; > + // initialize the other flags too: > + _has_finalizer = _has_empty_finalizer = _has_vanilla_constructor = false; > + _max_bootstrap_specifier_index = -1; > + } > + void apply_parsed_class_attributes(instanceKlassHandle k); // update k > + > class AnnotationCollector { > public: > enum Location { _in_field, _in_method, _in_class }; > > > @@ -2866,6 +2863,21 @@ > } > } > +void ClassFileParser::apply_parsed_class_attributes(instanceKlassHandle k) { > + if (_synthetic_flag) > + k->set_is_synthetic(); > + if (_sourcefile != NULL) { > + _sourcefile->increment_refcount(); > + k->set_source_file_name(_sourcefile); > + } > + if (_generic_signature != NULL) { > + _generic_signature->increment_refcount(); > + k->set_generic_signature(_generic_signature); > + } > + k->set_source_debug_extension(_sde_symbol); // increment_refcount inside > + k->set_inner_classes(_inner_classes()); > + k->set_class_annotations(_annotations()); > +} > typeArrayHandle ClassFileParser::assemble_annotations(u1* runtime_visible_annotations, > int runtime_visible_annotations_length, > From john.r.rose at oracle.com Thu Jul 12 02:11:58 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 12 Jul 2012 02:11:58 -0700 Subject: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering In-Reply-To: <4FFBF20F.7090600@univ-mlv.fr> References: <20120710084246.4DA2147ED3@hg.openjdk.java.net> <4FFBF20F.7090600@univ-mlv.fr> Message-ID: On Jul 10, 2012, at 2:12 AM, R?mi Forax wrote: > I think backtrace filtering, should be enhanced by adding a new method > attribute in the bytecode that indicates if a method should be visible > or not > when dumping a stacktrace and a display name that should be used > instead of the bytecode method name. > > This may reduce the need of stacktrace post-processing and makes Charles > happy. I'm don't think we've identified a sweet spot yet, but I encourage people to experiment. Eventually such a thing could make its way into a JSR (maybe in a MR). One problem with mixed mode systems is that a method like "executeMyLanguagesInterpretedMethodUntilItGetsCompiled" wants to display a method name based on some value inside the frame itself. Simply filtering or renaming JVM methods does not cover this case at all. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120712/d99d2fb7/attachment.html From john.r.rose at oracle.com Thu Jul 12 02:21:39 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 12 Jul 2012 09:21:39 +0000 Subject: hg: mlvm/mlvm/jdk: rebase after pushing 4 changesets to hotspot-comp Message-ID: <20120712092139.9A8F047FB1@hg.openjdk.java.net> Changeset: 421b98214f0d Author: jrose Date: 2012-07-12 02:21 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/421b98214f0d rebase after pushing 4 changesets to hotspot-comp - cval-7153157.patch - meth-7087658.patch - meth-7127687.patch - meth-7129034.patch ! series From rednaxelafx at gmail.com Thu Jul 12 02:35:29 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 12 Jul 2012 17:35:29 +0800 Subject: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering In-Reply-To: References: <20120710084246.4DA2147ED3@hg.openjdk.java.net> <4FFBF20F.7090600@univ-mlv.fr> Message-ID: Unconditionally skipping some special frames in the stack trace may also make language implementers' lives hard when they're *developing* - it's analogous to when JVM implementers want to see all frames of a stack, including the native/VM internal ones, where as most Java developers would just want Java frames. There are scenarios where unconditionally skipping some frames should always be good, like skipping some internal frames with regard to security checking, especially when such behavior is required by related specs. - Kris On Thu, Jul 12, 2012 at 5:11 PM, John Rose wrote: > On Jul 10, 2012, at 2:12 AM, R?mi Forax wrote: > > I think backtrace filtering, should be enhanced by adding a new method > attribute in the bytecode that indicates if a method should be visible > or not > when dumping a stacktrace and a display name that should be used > instead of the bytecode method name. > > This may reduce the need of stacktrace post-processing and makes Charles > happy. > > > I'm don't think we've identified a sweet spot yet, but I encourage people > to experiment. Eventually such a thing could make its way into a JSR > (maybe in a MR). > > One problem with mixed mode systems is that a method like > "executeMyLanguagesInterpretedMethodUntilItGetsCompiled" wants to display a > method name based on some value inside the frame itself. Simply filtering > or renaming JVM methods does not cover this case at all. > > ? John > > _______________________________________________ > 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/20120712/2ca5a746/attachment.html From john.r.rose at oracle.com Thu Jul 12 02:39:55 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 12 Jul 2012 02:39:55 -0700 Subject: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering In-Reply-To: References: <20120710084246.4DA2147ED3@hg.openjdk.java.net> <4FFBF20F.7090600@univ-mlv.fr> Message-ID: <8279E16A-34BC-4040-9799-75FB41D6E697@oracle.com> On Jul 12, 2012, at 2:35 AM, Krystal Mok wrote: > Unconditionally skipping some special frames in the stack trace may also make language implementers' lives hard when they're *developing* - it's analogous to when JVM implementers want to see all frames of a stack, including the native/VM internal ones, where as most Java developers would just want Java frames. Yes. Two points: There is a -XX flag to disable the filtering, and the low-level crash dumps (hs_err*.log) are unfiltered. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120712/33a30dc4/attachment.html From christian.thalinger at oracle.com Thu Jul 12 08:56:44 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 Jul 2012 08:56:44 -0700 Subject: How to making Class.forName work in indy? In-Reply-To: <4FFC973D.1020303@gmx.org> References: <4FFC8B96.7030906@gmx.org> <4FFC970D.1040006@univ-mlv.fr> <4FFC973D.1020303@gmx.org> Message-ID: On Jul 10, 2012, at 1:57 PM, Jochen Theodorou wrote: > Am 10.07.2012 22:56, schrieb R?mi Forax: > [...] >> Class.forName(name) is equivalent to Class.forName(name, true, >> lookup.lookupClass().getClassLoader()) >> As true and lookup.lookupClass().getClassLoader() are constant in the BSM, >> you can bound them using insertArguments. > > also an interesting idea, true, never thought of that... which is > exactly why I ask here ;) Remi has an answer for everything ;-) -- Chris > > bye blackdrag > > > -- > Jochen "blackdrag" Theodorou - Groovy Project Tech Lead > blog: http://blackdragsview.blogspot.com/ > german groovy discussion newsgroup: de.comp.lang.misc > For Groovy programming sources visit http://groovy-lang.org > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From headius at headius.com Thu Jul 12 10:14:08 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 12 Jul 2012 10:14:08 -0700 Subject: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering In-Reply-To: References: <20120710084246.4DA2147ED3@hg.openjdk.java.net> <4FFBF20F.7090600@univ-mlv.fr> Message-ID: On Thu, Jul 12, 2012 at 2:11 AM, John Rose wrote: > One problem with mixed mode systems is that a method like > "executeMyLanguagesInterpretedMethodUntilItGetsCompiled" wants to display a > method name based on some value inside the frame itself. Simply filtering > or renaming JVM methods does not cover this case at all. This is indeed the problem we face in JRuby. The Hidden annotation might help us hide JRuby internals used for call-to-call plumbing, but there's no static way to solve the problem of generating a trace for interpreter frames. Here's part of a Java trace from JRuby, with both compiled and interpreted bits in it: Trace snippit: at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:135) at org.jruby.ast.CallNoArgNode.interpret(CallNoArgNode.java:63) at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104) at org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:75) at org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:139) at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:175) at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:566) at org.jruby.runtime.invokedynamic.InvocationLinker.invocationFallback(InvocationLinker.java:149) at blah.method__0$RUBY$foo(blah.rb:4) at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:566) at org.jruby.runtime.invokedynamic.InvocationLinker.invocationFallback(InvocationLinker.java:149) at blah.__file__(blah.rb:13) at blah.load(blah.rb) To generate a Ruby backtrace from this, we use the Java backtrace as a "master" and mine out the interesting pieces. Specifically: 1. Elements with RUBY and __file__ in them are included because they represent compiled Ruby code. 2. Any Java-based Ruby method in the trace is included, using a list we maintain in JRuby as those methods are bound. 3. Interpreter entry points are indicated by INTERPRET_METHOD, INTERPRET_EVAL, and so on. For each such element, we insert backtrace data from our interpreter's backtrace stack (on heap) This works well for Ruby code but does often omit frames users *want* to see, like reflection-called Java methods. Hiding would work for removing elements, but we'd have to tag a large amount of JRuby code (like the entire interpreter) to remove everything. Having an annotation to indicate the actual method name would be useful for (2) above, but it would not do anything to help us dynamically determine the frame for an interpreted section. While I'd love to see better programmatic access to backtrace generation, I can't really envision what it would look like. On the plus side...the requirement that we always "assemble" our backtraces from bits and bobs means we can do fun things like alternative formatting and adding color :) http://min.us/mbIkONLut I dare say JRuby has the nicest stack traces of any language on the JVM. - Charlie From forax at univ-mlv.fr Thu Jul 12 10:50:53 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 12 Jul 2012 19:50:53 +0200 Subject: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering In-Reply-To: References: <20120710084246.4DA2147ED3@hg.openjdk.java.net> <4FFBF20F.7090600@univ-mlv.fr> Message-ID: <4FFF0E7D.7080601@univ-mlv.fr> On 07/12/2012 07:14 PM, Charles Oliver Nutter wrote: > On Thu, Jul 12, 2012 at 2:11 AM, John Rose wrote: >> One problem with mixed mode systems is that a method like >> "executeMyLanguagesInterpretedMethodUntilItGetsCompiled" wants to display a >> method name based on some value inside the frame itself. Simply filtering >> or renaming JVM methods does not cover this case at all. > This is indeed the problem we face in JRuby. The Hidden annotation > might help us hide JRuby internals used for call-to-call plumbing, but > there's no static way to solve the problem of generating a trace for > interpreter frames. I agree, but it will greatly simplify the problem because stacktrace will be smaller so it will be faster to patched them. > > Here's part of a Java trace from JRuby, with both compiled and > interpreted bits in it: > > Trace snippit: > > at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:135) > at org.jruby.ast.CallNoArgNode.interpret(CallNoArgNode.java:63) > at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104) > at org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:75) > at org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:139) > at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:175) > at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:566) > at org.jruby.runtime.invokedynamic.InvocationLinker.invocationFallback(InvocationLinker.java:149) > at blah.method__0$RUBY$foo(blah.rb:4) > at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:566) > at org.jruby.runtime.invokedynamic.InvocationLinker.invocationFallback(InvocationLinker.java:149) > at blah.__file__(blah.rb:13) > at blah.load(blah.rb) > > To generate a Ruby backtrace from this, we use the Java backtrace as a > "master" and mine out the interesting pieces. Specifically: > > 1. Elements with RUBY and __file__ in them are included because they > represent compiled Ruby code. > 2. Any Java-based Ruby method in the trace is included, using a list > we maintain in JRuby as those methods are bound. > 3. Interpreter entry points are indicated by INTERPRET_METHOD, > INTERPRET_EVAL, and so on. For each such element, we insert backtrace > data from our interpreter's backtrace stack (on heap) > > This works well for Ruby code but does often omit frames users *want* > to see, like reflection-called Java methods. > > Hiding would work for removing elements, but we'd have to tag a large > amount of JRuby code (like the entire interpreter) to remove > everything. Having an annotation to indicate the actual method name > would be useful for (2) above, but it would not do anything to help us > dynamically determine the frame for an interpreted section. > > While I'd love to see better programmatic access to backtrace > generation, I can't really envision what it would look like. A special method handle acting as a decorator should be enough :) Let say we have a static method backtraceDecorator in MethodHandles that takes a target method handle and returns a new method handle. The new method handle will have a supplementary parameter of type String before all parameters, the content of this parameter will be used instead of the method name of the target method in the stack trace. So basically, the handle handle will change the method name of the method handle taken as argument, so the target method handle must be either a constant method handle or the result of a lookup.find* or lookup.unreflect*. Now in the runtime instead of calling INTERPRET_METHOD directly, the runtime should call the method handle created like this: MethodHandle interpreterEntryPoint = MethodHandles.backtraceDecorator( lookup.findVirtual(..., ''INTERPRET_METHOD")); and this method handle should be called with the method name as first parameter. > > On the plus side...the requirement that we always "assemble" our > backtraces from bits and bobs means we can do fun things like > alternative formatting and adding color :) > > http://min.us/mbIkONLut > > I dare say JRuby has the nicest stack traces of any language on the JVM. > > - Charlie cheers, R?mi From szegedia at gmail.com Thu Jul 12 16:08:26 2012 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 12 Jul 2012 16:08:26 -0700 Subject: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering In-Reply-To: References: <20120710084246.4DA2147ED3@hg.openjdk.java.net> <4FFBF20F.7090600@univ-mlv.fr> Message-ID: On Thu, Jul 12, 2012 at 10:14 AM, Charles Oliver Nutter wrote: > > I dare say JRuby has the nicest stack traces of any language on the JVM. Well, as far as showing pride in the way you tackle error reporting, I'm actually very proud of the level of detail we put into exception reporting for FreeMarker. Just Googling "The problematic instruction ftl" gives some nice examples on the web, here's one from . If you look at it, you'll notice it's carefully formatted for human readability - the whole logged string is how FreeMarker formats the exception message. It starts with the statemet of the problem and hints at a possible cause. This is followed by a language specific stack trace (which shows the offending instruction, and then any includes/imports/function calls it might be in, here it's only a single include, so it's quite shallow). Since this is a templating language, it prints not only the line number, but the column number of the instructions. Finally the actual Java stack trace, delineated and labeled "for programmers" (to distinguish the audience - it's not supposed to be interesting for template authors). Sometimes the contrast between the sizes of the high-level language stack trace and the lower level (Java) trace is quite staggering, i.e. , which just goes to show this is something that language implementers really need to pay attention to. Attila. From vladimir.kozlov at oracle.com Thu Jul 12 18:27:31 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Jul 2012 18:27:31 -0700 Subject: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: References: Message-ID: <4FFF7983.3050905@oracle.com> John, sharedRuntime_sparc.cpp: Why casting to (int)? Also use pointer_delta(code_end, code_start,1): + __ set((int)(intptr_t)(code_end - code_start), temp2_reg); You bound L_fail label twice, it should be local in range_check(). Use brx() instead of br() since you compare pointers. And use cmp_and_brx_short() if delayed instruction is nop(). Use fatal() instead of guarantee: guarantee(false, err_msg("special_dispatch=%d", special_dispatch)); interpreter_sparc.cpp: In generate_method_entry() use fatal() instead of ShouldNotReachHere(): fatal(err_msg("unexpected method kind: %d", kind)); methodHandles_sparc.cpp: In MethodHandles::verify_klass() calls restore() should be after BINDs. In MethodHandles::jump_from_method_handle() use cmp_and_br_short(temp, 0, ) Instead of 100 use strlen(name)+50: + char* qname = NEW_C_HEAP_ARRAY(char, 100); + jio_snprintf(qname, 100, sharedRuntime_x86_32.cpp: sharedRuntime_x86_64.cpp: The same problem with L_fail label as in sharedRuntime_sparc.cpp. templateInterpreter_x86_32.cpp: templateInterpreter_x86_64.cpp: Again use use fatal() instead of ShouldNotReachHere() in generate_method_entry() I see in several files next code pattern. Should we call throw_IncompatibleClassChangeError() as we do in other places?: + if (!EnableInvokeDynamic) { + // rewriter does not generate this bytecode + __ should_not_reach_here(); + return; + } c1_FrameMap.cpp: Why is ShouldNotReachHere() for mh_invoke in FrameMap::java_calling_convention()? c1_GraphBuilder.cpp: add parenthesis: const bool is_invokedynamic = code == Bytecodes::_invokedynamic; nmethod.cpp: Don't put printing nmethod's addresses under Verbose flag. linkResolver.cpp: Can you replace infinite for(;;) in resolve_invokedynamic() with finite loop since the body is executed once or twice. templateInterpreter.cpp: why you need additional {} around the loop? constantPoolOop.cpp: Why not use guarantee() for bad operants? Why you need separate scopes in resolve_bootstrap_specifier_at_impl()? symbol.cpp: The loop in index_of_at() should be for(; scan <= limit; scan++) and after loop return -1. bytecodeInfo.cpp: Don't add spaces into conditions, looks strange. Remove commented code for inline ForceInline methods. callGenerator.cpp: Please, decide which code to use: +#if 1. And I don't think new code is correct. graphKit.cpp: Remove commented debug print. insert_argument() and remove_argument() are not used. Vladimir John Rose wrote: > As some of you have noticed, Chris Thalinger, Michael Haupt, and I have been working on the mlvm patches [1] for JEP-160 [2] for several months. These changes make method handles more optimizable. They refactor lots of "magic" out of the JVM and into more manageable Java code. > > To get an idea of how much "magic" is being removed, consider that the change removes 12,000 lines of non-comment code from the JVM, including much assembly code. It inserts 4900 lines of non-comment code. > > These changes are now stable enough to integrate. They pass jtreg tests in a number of execution modes and platforms. They also correctly run various JRuby and Nashorn test programs. Although there are no performance gains to boast about at present, these changes clear the ground for long-term optimization work. > > Here is the webrev [3], for review and integration into JDK 8 via hotspot-comp/hotspot/. > > Because of the large size of this change set, we request that reviewers would clearly designate which files they are reviewing. That way we may be able to divide up the work a little more effectively. > > Also, because of the scope of the change, we may respond to some comments by promising to address an issue in a future change set. If necessary, we will file tracking bugs to make sure nothing gets dropped. We have been working on this for months, and expect to make many further changes. > > The immediate need to get the changes in is twofold: First, some bugs (involving symbolic references off the boot class path) require the new Lambda Form intermediate representation, which is "off-BCP-clean". Second, we need to commit our pervasive changes to the JVM sooner rather than later, so they can be properly integrated with other pervasive changes, such as metadata changes. > > An associated webrev for hotspot-comp/jdk/ will be posted soon; it is already present on mlvm-dev for the curious to examine. (This change set also deletes a lot of old code.) > > Thanks in advance, > ? John > > [1] http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy-7023639.patch > [2] http://openjdk.java.net/jeps/160 > [3] http://cr.openjdk.java.net/~jrose/7023639/webrev.00/ > From christian.thalinger at oracle.com Thu Jul 12 18:47:25 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 13 Jul 2012 01:47:25 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: misc. SPARC fixes Message-ID: <20120713014725.856A847FEE@hg.openjdk.java.net> Changeset: f55844a06cc2 Author: twisti Date: 2012-07-12 18:47 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f55844a06cc2 meth-lazy: misc. SPARC fixes ! meth-lazy-7023639.patch From stephen.bannasch at deanbrook.org Thu Jul 12 21:08:25 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Fri, 13 Jul 2012 00:08:25 -0400 Subject: Testing out latest work In-Reply-To: References: Message-ID: At 1:32 PM -0700 7/11/12, Charles Oliver Nutter wrote: >Ok, gents, Christian told me now might be a good time to start poking >at the new indy backend with JRuby, so I got a build together and have >been playing with it a bit. > >First off, getting it to build... > >Stephen B's gist still works fine: https://gist.github.com/243072 > >But I had to issue one additional command to get xcode tools in the >right places for command-line build of OpenJDK: > >sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer > >This is latest Lion and Xcode (4.3.2). I previously installed the >command-line tools through the Xcode interface. Thanks for the feedback. I fixed the BUILD location to reference the j2sdk-bundle in the script so when the result is copied to: ~/Library/Java/JavaVirtualMachines you get a JVM that shows up properly running: /usr/libexec/java_home --version 1.8 -V I also cleaned up the documentation in the comments and added the "xcode-select -switch" tip. https://gist.github.com/243072 From michael.haupt at oracle.com Fri Jul 13 01:46:00 2012 From: michael.haupt at oracle.com (michael.haupt at oracle.com) Date: Fri, 13 Jul 2012 08:46:00 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: removed obsolete DataBinding interface and commented-out code Message-ID: <20120713084601.30D724701D@hg.openjdk.java.net> Changeset: 4d38d18ba364 Author: mhaupt Date: 2012-07-13 10:45 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/4d38d18ba364 meth-lazy: removed obsolete DataBinding interface and commented-out code ! meth-lazy-7023639.xbmh.patch From john.r.rose at oracle.com Fri Jul 13 02:18:40 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 13 Jul 2012 09:18:40 +0000 Subject: hg: mlvm/mlvm/jdk: 2 new changesets Message-ID: <20120713091840.91CC24701E@hg.openjdk.java.net> Changeset: 4deb4756153e Author: jrose Date: 2012-07-13 01:55 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/4deb4756153e meth: reorder series ! meth-lazy-7023639.patch ! meth.patch ! series Changeset: 8e60c519b9f8 Author: jrose Date: 2012-07-13 02:18 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/8e60c519b9f8 meth: merge xbmh patch into main patch for review ! meth-lazy-7023639.patch - meth-lazy-7023639.xbmh.patch ! series From john.r.rose at oracle.com Fri Jul 13 02:32:13 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 13 Jul 2012 09:32:13 +0000 Subject: hg: mlvm/mlvm/jdk: meth: move misc. doc clarification into the big patch Message-ID: <20120713093213.EF7284701F@hg.openjdk.java.net> Changeset: 8bf7abfe2a9d Author: jrose Date: 2012-07-13 02:32 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/8bf7abfe2a9d meth: move misc. doc clarification into the big patch ! meth-lazy-7023639.patch ! meth.patch From john.r.rose at oracle.com Fri Jul 13 02:35:43 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 13 Jul 2012 09:35:43 +0000 Subject: hg: mlvm/mlvm/jdk: meth: forgot to hg add MethodHandleInfo.java Message-ID: <20120713093543.B803247021@hg.openjdk.java.net> Changeset: 22468f6f518d Author: jrose Date: 2012-07-13 02:35 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/22468f6f518d meth: forgot to hg add MethodHandleInfo.java ! meth-lazy-7023639.patch From john.r.rose at oracle.com Fri Jul 13 02:41:21 2012 From: john.r.rose at oracle.com (John Rose) Date: Fri, 13 Jul 2012 02:41:21 -0700 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: References: Message-ID: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> On Jul 11, 2012, at 5:53 PM, John Rose wrote: > As some of you have noticed, Chris Thalinger, Michael Haupt, and I have been working on the mlvm patches [1] for JEP-160 [2] for several months. These changes make method handles more optimizable. They refactor lots of "magic" out of the JVM and into more manageable Java code. > ? > An associated webrev for hotspot-comp/jdk/ will be posted soon; it is already present on mlvm-dev for the curious to examine. (This change set also deletes a lot of old code.) Here is that webrev: http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.00/ These are the changes to JDK code that accompany the JVM changes already under review. There are 2900 LOC deleted, and 7000 LOC added. Key changes: - method handle behavior is fully represented by LambdaForm objects - chained method handles (including "adapter method handles") are gone - an ASM-based bytecode spinner compiles LambdaForms when they warm up - bound method handles are compactly represented without boxing - the private symbol-resolution interface to the JVM (MemberName) is improved - unit tests have more systematic coverage - a number of minor bugs are fixed This is implementation work. No public Java APIs are changed, although the javadoc is slightly edited for clarity. Please have a look. ? John From christian.thalinger at oracle.com Fri Jul 13 11:19:23 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 13 Jul 2012 18:19:23 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: probably missed during last merge Message-ID: <20120713181924.31E0C47030@hg.openjdk.java.net> Changeset: a436cf481411 Author: twisti Date: 2012-07-13 11:18 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a436cf481411 meth-lazy: probably missed during last merge ! meth-lazy-7023639.patch From vladimir.kozlov at oracle.com Fri Jul 13 11:36:23 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 Jul 2012 11:36:23 -0700 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> References: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> Message-ID: <50006AA7.1040601@oracle.com> BoundMethodHandle.java: I am concern that BMH subclass names are looks like constants names: BMH_LLI. In several places you have BMH constants and variables: + final Class BMH = BoundMethodHandle.class; + static final String BMH = "java/lang/invoke/BoundMethodHandle"; ThrowExceptionsTest.java: empty diffs ValueConversionsTest.java: remove commented print statement if it is not needed: - System.out.println(arrayType.getSimpleName()); + //System.out.println(arrayType.getSimpleName()); Vladimir John Rose wrote: > On Jul 11, 2012, at 5:53 PM, John Rose wrote: > >> As some of you have noticed, Chris Thalinger, Michael Haupt, and I have been working on the mlvm patches [1] for JEP-160 [2] for several months. These changes make method handles more optimizable. They refactor lots of "magic" out of the JVM and into more manageable Java code. >> ? >> An associated webrev for hotspot-comp/jdk/ will be posted soon; it is already present on mlvm-dev for the curious to examine. (This change set also deletes a lot of old code.) > > Here is that webrev: > http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.00/ > > These are the changes to JDK code that accompany the JVM changes already under review. > > There are 2900 LOC deleted, and 7000 LOC added. Key changes: > - method handle behavior is fully represented by LambdaForm objects > - chained method handles (including "adapter method handles") are gone > - an ASM-based bytecode spinner compiles LambdaForms when they warm up > - bound method handles are compactly represented without boxing > - the private symbol-resolution interface to the JVM (MemberName) is improved > - unit tests have more systematic coverage > - a number of minor bugs are fixed > > This is implementation work. No public Java APIs are changed, although the javadoc is slightly edited for clarity. > > Please have a look. > > ? John From headius at headius.com Fri Jul 13 16:04:27 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 13 Jul 2012 16:04:27 -0700 Subject: Testing out latest work In-Reply-To: References: Message-ID: Ok, updates. Still looking good on general stability. Perf is a mixed bag but still usually faster than non-indy. I have run into my first obvious behavioral difference between the new and old code: the "name" argument (2nd arg) to bootstrap methods was interned under the old backend, but is not in the new backend. I don't know if there's anything in the spec to indicate it should be interned, but I figured I'd bring it up. It was the source of many test failures in JRuby because we had a key BSM that expected interned Strings. I'm working my way through JRuby's jit.threshold=0 and AOT test suites, and so far that's the only indy-related issue. I'm looking into another test that seems to fail sporadically but only on MLVM. - Charlie From john.r.rose at oracle.com Fri Jul 13 22:34:39 2012 From: john.r.rose at oracle.com (John Rose) Date: Fri, 13 Jul 2012 22:34:39 -0700 Subject: Testing out latest work In-Reply-To: References: Message-ID: <846A7D7F-0FF4-42A1-A1AF-29B8FDDD71A4@oracle.com> On Jul 13, 2012, at 4:04 PM, Charles Oliver Nutter wrote: > Still looking good on general stability. Perf is a mixed bag but still > usually faster than non-indy. Well, that's better than slower. We are going to shake out lots of perf. problems after we get this next push done. > I have run into my first obvious behavioral difference between the new > and old code: the "name" argument (2nd arg) to bootstrap methods was > interned under the old backend, but is not in the new backend. I don't > know if there's anything in the spec to indicate it should be > interned, but I figured I'd bring it up. It was the source of many > test failures in JRuby because we had a key BSM that expected interned > Strings. Oops, I'll intern the strings. I see no reason not to. It is slightly surprising when strings which originate in the constant pool are *not* interned. > I'm working my way through JRuby's jit.threshold=0 and AOT test > suites, and so far that's the only indy-related issue. I'm looking > into another test that seems to fail sporadically but only on MLVM. Thanks. Good news so far. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120713/2168137a/attachment.html From schlosna at gmail.com Sat Jul 14 05:02:07 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Sat, 14 Jul 2012 08:02:07 -0400 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> References: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> Message-ID: On Fri, Jul 13, 2012 at 5:41 AM, John Rose wrote: > On Jul 11, 2012, at 5:53 PM, John Rose wrote: > >> As some of you have noticed, Chris Thalinger, Michael Haupt, and I have been working on the mlvm patches [1] for JEP-160 [2] for several months. These changes make method handles more optimizable. They refactor lots of "magic" out of the JVM and into more manageable Java code. >> ? >> An associated webrev for hotspot-comp/jdk/ will be posted soon; it is already present on mlvm-dev for the curious to examine. (This change set also deletes a lot of old code.) > > Here is that webrev: > http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.00/ > > These are the changes to JDK code that accompany the JVM changes already under review. > > There are 2900 LOC deleted, and 7000 LOC added. Key changes: > - method handle behavior is fully represented by LambdaForm objects > - chained method handles (including "adapter method handles") are gone > - an ASM-based bytecode spinner compiles LambdaForms when they warm up > - bound method handles are compactly represented without boxing > - the private symbol-resolution interface to the JVM (MemberName) is improved > - unit tests have more systematic coverage > - a number of minor bugs are fixed > > This is implementation work. No public Java APIs are changed, although the javadoc is slightly edited for clarity. > > Please have a look. > > ? John John, I had a few quick comments on your webrev. Some of these might be considered premature or unnecessary optimization, so take them as you wish. src/share/classes/java/lang/invoke/BoundMethodHandle.java On lines 131-132: Just out of curiosity, why use pos+1 in one line versus 1+pos on the next? Would it be worthwhile to extract pos+1 to a local int end to save some bytecode? MethodHandle bindArgument(int pos, char basicType, Object value) { int end = pos + 1; MethodType type = type().dropParameterTypes(pos, end); LambdaForm form = internalForm().bind(basicType, end, tcount()); if (basicType == 'I' && !(value instanceof Integer)) { // Cf. ValueConversions.unboxInteger value = ValueConversions.primitiveConversion(Wrapper.INT, value, true); } return cloneExtend(type, form, basicType, value); } On lines 202-212: Similarly would it be worthwhile to extract types() to a local String within internalValues()? final Object internalValues() { String types = types(); Object[] boundValues = new Object[types.length()]; for (int i = 0; i < boundValues.length; ++i) { try { switch (types.charAt(i)) { case 'L': boundValues[i] = argL(i); break; case 'I': boundValues[i] = argI(i); break; case 'F': boundValues[i] = argF(i); break; case 'D': boundValues[i] = argD(i); break; case 'J': boundValues[i] = argJ(i); break; default : throw new InternalError("unexpected type: " + types.charAt(i)); } } catch (Throwable t) { throw new InternalError(t); } } return Arrays.asList(boundValues); } On line 464: Is there any reason CACHE should not be final? static final Map CACHE = new IdentityHashMap<>(); On lines 473-486: Do the accesses and mutations of CACHE need to be thread safe or are the uses assumed to be safe by other means? On lines 778-784: Should this use types.charAt(int) rather than toCharArray() to copy the array? private static String makeSignature(String types, boolean ctor) { StringBuilder buf = new StringBuilder(SIG_INCIPIT); for (int i = 0; i < types.length(); ++i) { buf.append(typeSig(types.charAt(i))); } return buf.append(')').append(ctor ? "V" : BMH_SIG).toString(); } Would it be worthwhile for clarity to define constants to represent the BaseTypes ('B', 'C', 'D', 'F', 'I', 'J', 'S', 'Z') and ObjectType ('L') per JVM spec section 4.3.2 for use throughout these java.lang.invoke.* implementation classes (e.g. the various switch/case in BoundMethodHandle, and DirectMethodHandle.bindArgument, throughout LambdaForm)? I assume that anyone touching this code would be familiar with these types so constants may actually reduce clarity for some developers. src/share/classes/java/lang/invoke/CountingMethodHandle.java On line 40: Should instance field target be final? private final MethodHandle target; src/share/classes/java/lang/invoke/Invokers.java On lines 322-326: Is this err.initCause(ex) needed since the cause is already passed to the 2 arg InternalError constructor (maybe leftover from before the constructor was added in JDK8)? } catch (Exception ex) { throw new InternalError("Exception while resolving inexact invoke", ex); } src/share/classes/java/lang/invoke/MemberName.java On lines 81-90 there is an implementation of equals(Object), but on lines 593-603 there is a commented out implementation of equals(Object) and hashCode(). Are the commented out versions for future usage? There should probably be an implementation of hashCode() consistent with equals, although MemberName may not be used in a hash based structure. Also, it might be worthwhile to collocate the "TO BE" implementations with near the current ones with a comment. On lines 268-278: Should the isObjectPublicMethod() method also match public Object methods getClass(), notify(), notifyAll(), wait(), wait(long), and wait(long, int) or are those not intended to be used? src/share/classes/java/lang/invoke/SimpleMethodHandle.java On lines 41-45: Just out of curiosity, why use pos+1 in one line versus 1+pos on the next? Would it be worthwhile to extract pos+1 to a local int end to save some bytecode? MethodHandle bindArgument(int pos, char basicType, Object value) { int end = pos + 1; MethodType type2 = type().dropParameterTypes(pos, end); LambdaForm form2 = internalForm().bind(basicType, end, 0); return BoundMethodHandle.bindSingle(type2, form2, basicType, value); } Thanks, Dave From forax at univ-mlv.fr Sat Jul 14 05:43:32 2012 From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=) Date: Sat, 14 Jul 2012 14:43:32 +0200 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: References: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> Message-ID: <50016974.70200@univ-mlv.fr> On 07/14/2012 02:02 PM, David Schlosnagle wrote: > On Fri, Jul 13, 2012 at 5:41 AM, John Rose > wrote: >> On Jul 11, 2012, at 5:53 PM, John Rose wrote: >> >>> As some of you have noticed, Chris Thalinger, Michael Haupt, and I >>> have been working on the mlvm patches [1] for JEP-160 [2] for >>> several months. These changes make method handles more >>> optimizable. They refactor lots of "magic" out of the JVM and into >>> more manageable Java code. >>> ? >>> An associated webrev for hotspot-comp/jdk/ will be posted soon; it >>> is already present on mlvm-dev for the curious to examine. (This >>> change set also deletes a lot of old code.) >> Here is that webrev: >> http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.00/ >> >> These are the changes to JDK code that accompany the JVM changes >> already under review. >> >> There are 2900 LOC deleted, and 7000 LOC added. Key changes: >> - method handle behavior is fully represented by LambdaForm objects >> - chained method handles (including "adapter method handles") are gone >> - an ASM-based bytecode spinner compiles LambdaForms when they warm up >> - bound method handles are compactly represented without boxing >> - the private symbol-resolution interface to the JVM (MemberName) >> is improved >> - unit tests have more systematic coverage >> - a number of minor bugs are fixed >> >> This is implementation work. No public Java APIs are changed, >> although the javadoc is slightly edited for clarity. >> >> Please have a look. >> >> ? John > John, Hi David, I hijack the thread ... > > I had a few quick comments on your webrev. Some of these might be > considered premature or unnecessary optimization, so take them as you > wish. > > src/share/classes/java/lang/invoke/BoundMethodHandle.java > > On lines 131-132: Just out of curiosity, why use pos+1 in one line > versus 1+pos on the next? Would it be worthwhile to extract pos+1 to a > local int end to save some bytecode? > MethodHandle bindArgument(int pos, char basicType, Object value) { > int end = pos + 1; > MethodType type = type().dropParameterTypes(pos, end); > LambdaForm form = internalForm().bind(basicType, end, tcount()); > if (basicType == 'I' && !(value instanceof Integer)) { > // Cf. ValueConversions.unboxInteger > value = ValueConversions.primitiveConversion(Wrapper.INT, > value, true); > } > return cloneExtend(type, form, basicType, value); > } Usually you should not care about this kind of change, micro-optimizing is useless. Or this code is not called enough and you don't care or this code is hot and the JIT will do what should be done and because the JIT may inline the code of dropParameterTypes and bind(), it will better optimize that you because it will be able to share more sub-expressions. Now just for fun, if you count the number of bytecodes, I think your proposed code is bigger because 'end' is the local variable 4 and the is no istore_4/iload_4 so the compiler will use the generic iload/istore which takes 2 bytes. so pos + 1 is iload_1, iconst_1, iadd, so the current version use 6 bytecodes, your version use iload_1, iconst_1, iadd, istore 4 + iload 4 * 2= 9 bytecodes > > On lines 202-212: Similarly would it be worthwhile to extract types() > to a local String within internalValues()? > final Object internalValues() { > String types = types(); > Object[] boundValues = new Object[types.length()]; > for (int i = 0; i < boundValues.length; ++i) { > try { > switch (types.charAt(i)) { > case 'L': boundValues[i] = argL(i); break; > case 'I': boundValues[i] = argI(i); break; > case 'F': boundValues[i] = argF(i); break; > case 'D': boundValues[i] = argD(i); break; > case 'J': boundValues[i] = argJ(i); break; > default : throw new InternalError("unexpected type: " > + types.charAt(i)); > } > } catch (Throwable t) { > throw new InternalError(t); > } > } > return Arrays.asList(boundValues); > } default case should never be called, so don't 'optimize' for it. > > On line 464: Is there any reason CACHE should not be final? > static final Map CACHE = new IdentityHashMap<>(); this one may be important, static final => const for the VM > > On lines 473-486: Do the accesses and mutations of CACHE need to be > thread safe or are the uses assumed to be safe by other means? > > On lines 778-784: Should this use types.charAt(int) rather than > toCharArray() to copy the array? > private static String makeSignature(String types, boolean > ctor) { > StringBuilder buf = new StringBuilder(SIG_INCIPIT); > for (int i = 0; i < types.length(); ++i) { > buf.append(typeSig(types.charAt(i))); > } > return buf.append(')').append(ctor ? "V" : > BMH_SIG).toString(); > } toCharArray() may be more efficient because when you iterate on the result, the VM can remove the bound checks. It's harder to do the same with String.charAt() because String are respresented with an offset and a length different, note that this is not true anymore for jdk8, a recent patch remove sharing between strings (to make them more optimizable). Anyway, the real question here, how often this code will be called and even if this code is called often, it's perhaps not a bottleneck. > Would it be worthwhile for clarity to define constants to represent > the BaseTypes ('B', 'C', 'D', 'F', 'I', 'J', 'S', 'Z') and ObjectType > ('L') per JVM spec section 4.3.2 for use throughout these > java.lang.invoke.* implementation classes (e.g. the various > switch/case in BoundMethodHandle, and DirectMethodHandle.bindArgument, > throughout LambdaForm)? I assume that anyone touching this code would > be familiar with these types so constants may actually reduce clarity > for some developers. > > > src/share/classes/java/lang/invoke/CountingMethodHandle.java > > On line 40: Should instance field target be final? > private final MethodHandle target; yes. > > > src/share/classes/java/lang/invoke/Invokers.java > > On lines 322-326: Is this err.initCause(ex) needed since the cause is > already passed to the 2 arg InternalError constructor (maybe leftover > from before the constructor was added in JDK8)? > } catch (Exception ex) { > throw new InternalError("Exception while resolving inexact > invoke", ex); > } > > src/share/classes/java/lang/invoke/MemberName.java > > On lines 81-90 there is an implementation of equals(Object), but on > lines 593-603 there is a commented out implementation of > equals(Object) and hashCode(). Are the commented out versions for > future usage? There should probably be an implementation of hashCode() > consistent with equals, although MemberName may not be used in a hash > based structure. Also, it might be worthwhile to collocate the "TO BE" > implementations with near the current ones with a comment. > > On lines 268-278: Should the isObjectPublicMethod() method also match > public Object methods getClass(), notify(), notifyAll(), wait(), > wait(long), and wait(long, int) or are those not intended to be used? > > > > src/share/classes/java/lang/invoke/SimpleMethodHandle.java > > On lines 41-45: Just out of curiosity, why use pos+1 in one line > versus 1+pos on the next? Would it be worthwhile to extract pos+1 to a > local int end to save some bytecode? > MethodHandle bindArgument(int pos, char basicType, Object value) { > int end = pos + 1; > MethodType type2 = type().dropParameterTypes(pos, end); > LambdaForm form2 = internalForm().bind(basicType, end, 0); > return BoundMethodHandle.bindSingle(type2, form2, basicType, > value); see above. > } > > > Thanks, > Dave cheers, R?mi From stephen.bannasch at deanbrook.org Sat Jul 14 07:12:39 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sat, 14 Jul 2012 10:12:39 -0400 Subject: new error building mlvm: nvoke/AdapterMethodHandle no class def found Message-ID: Am now getting this error building on 106.8 and 10.7.4. Build successfull just a couple of days ago -- so presumably the cause is a very recent change. /Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -cp /Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/classes sun.rmi.rmic.Main -classpath "/Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/classes" \ -d /Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/classes \ -v1.2 \ -keepgenerated \ javax.management.remote.rmi.RMIConnectionImpl Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle make[5]: *** [/Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class] Error 1 make[4]: *** [all] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 m From headius at headius.com Sat Jul 14 08:43:03 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 14 Jul 2012 08:43:03 -0700 Subject: Testing out latest work In-Reply-To: <846A7D7F-0FF4-42A1-A1AF-29B8FDDD71A4@oracle.com> References: <846A7D7F-0FF4-42A1-A1AF-29B8FDDD71A4@oracle.com> Message-ID: On Jul 14, 2012 12:35 AM, "John Rose" wrote: > > On Jul 13, 2012, at 4:04 PM, Charles Oliver Nutter wrote: >> I have run into my first obvious behavioral difference between the new >> and old code: the "name" argument (2nd arg) to bootstrap methods was >> interned under the old backend, but is not in the new backend. I don't >> know if there's anything in the spec to indicate it should be >> interned, but I figured I'd bring it up. It was the source of many >> test failures in JRuby because we had a key BSM that expected interned >> Strings. > > > Oops, I'll intern the strings. I see no reason not to. It is slightly surprising when strings which originate in the constant pool are *not* interned. Yeah, that's where my expectation came from. Granted, the name alone is not found in the constant pool, but it still seemed like it should be interned. - Charlie (mobile) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120714/684d1b4c/attachment.html From john.r.rose at oracle.com Sat Jul 14 13:52:14 2012 From: john.r.rose at oracle.com (John Rose) Date: Sat, 14 Jul 2012 13:52:14 -0700 Subject: new error building mlvm: nvoke/AdapterMethodHandle no class def found In-Reply-To: References: Message-ID: On Jul 14, 2012, at 7:12 AM, Stephen Bannasch wrote: > /Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions > -XX:-LogVMOutput -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -cp > /Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/classes sun.rmi.rmic.Main -classpath > "/Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/classes" \ > -d /Users/stephen/dev/java/src/mlvm/sources/build/macosx-x86_64/classes \ > -v1.2 \ > -keepgenerated \ > javax.management.remote.rmi.RMIConnectionImpl > Error occurred during initialization of VM > java/lang/NoClassDefFoundError: java/lang/invoke/AdapterMethodHandle I've seen errors like this too. They come from accidentally mixing an old libjvm.dylib with a new rt.jar, or vice versa. Because new only works with new and old with old, there will be a flurry of such errors in various places, until the new is everywhere. The error above suggests that an old libjvm.dylib is waking up and looking around for AdapterMethodHandle, which is not part of the new rt.jar. (It is a private implementation component found only in old the rt.jar.) I don't see an -Xbootclasspath in your command line, so I'm guessing that your build/macosx-x86_64 has a mix of old rt.jar and new libjvm.dylib in it, somehow. Perhaps hotspot.log has a clue as to why. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120714/98ea8e64/attachment.html From john.r.rose at oracle.com Sat Jul 14 17:56:50 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 15 Jul 2012 00:56:50 +0000 Subject: hg: mlvm/mlvm/hotspot: rebase to current hsx/hotspot-comp Message-ID: <20120715005650.EFB7B47049@hg.openjdk.java.net> Changeset: f128e52774bf Author: jrose Date: 2012-07-14 17:56 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f128e52774bf rebase to current hsx/hotspot-comp - annot-6711908.patch ! series From john.r.rose at oracle.com Sat Jul 14 17:57:30 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 15 Jul 2012 00:57:30 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: tweak ShowHiddenFrames behavior to disclose BCIs as well Message-ID: <20120715005730.D8A564704B@hg.openjdk.java.net> Changeset: 481644d9a6c5 Author: jrose Date: 2012-07-14 17:57 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/481644d9a6c5 meth: tweak ShowHiddenFrames behavior to disclose BCIs as well + meth-lazy-7023639.review.patch ! series From john.r.rose at oracle.com Sat Jul 14 18:02:50 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 15 Jul 2012 01:02:50 +0000 Subject: hg: mlvm/mlvm/jdk: meth: performance work Message-ID: <20120715010250.BCC604704F@hg.openjdk.java.net> Changeset: 56879e348afe Author: jrose Date: 2012-07-14 18:02 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/56879e348afe meth: performance work + meth-lazy-7023639.bmh.patch + meth-lazy-7023639.init.patch ! series From john.r.rose at oracle.com Sun Jul 15 04:32:51 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 15 Jul 2012 11:32:51 +0000 Subject: hg: mlvm/mlvm/jdk: meth: DirectMethodHandle.Accessor Message-ID: <20120715113251.A5FD04706E@hg.openjdk.java.net> Changeset: 32510db69498 Author: jrose Date: 2012-07-15 04:32 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/32510db69498 meth: DirectMethodHandle.Accessor ! meth-lazy-7023639.bmh.patch From stephen.bannasch at deanbrook.org Sun Jul 15 15:57:17 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sun, 15 Jul 2012 18:57:17 -0400 Subject: python errors running hg qselect --pop in sources dir Message-ID: Recently upgraded to Python 2.7.3 and Mercurial 2.2.2 (on Mac OS X 10.6.8 using brew) and am getting an error in python trying to pop a patch from the MLVM sources/ dir. However I'm NOT getting any errors popping patches from any other source directory. Has anybody else seen a problem like this? ---- details ---- [sources ]$ sh $davinci/patches/make/current-release.sh 1533dfab9903 [sources ]$ hg qselect --pop buildable testable bsd-port 1533dfab9903 ** unknown exception encountered, please report by visiting ** http://mercurial.selenic.com/wiki/BugTracker ** Python 2.7.3 (default, Jul 11 2012, 01:55:06) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] ** Mercurial Distributed SCM (version 2.2.2) ** Extensions loaded: forest, mq, hgk, fetch, rebase, hggit Traceback (most recent call last): File "/usr/local/bin/hg", line 38, in mercurial.dispatch.run() File "/usr/local/Cellar/mercurial/2.2.2/libexec/mercurial/dispatch.py", line 27, in run sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255) File "/usr/local/Cellar/mercurial/2.2.2/libexec/mercurial/dispatch.py", line 64, in dispatch return _runcatch(req) File "/usr/local/Cellar/mercurial/2.2.2/libexec/mercurial/dispatch.py", line 87, in _runcatch return _dispatch(req) File "/usr/local/Cellar/mercurial/2.2.2/libexec/mercurial/dispatch.py", line 696, in _dispatch cmdpats, cmdoptions) File "/usr/local/Cellar/mercurial/2.2.2/libexec/mercurial/dispatch.py", line 472, in runcommand ret = _runcommand(ui, options, cmd, d) File "/usr/local/Cellar/mercurial/2.2.2/libexec/mercurial/dispatch.py", line 786, in _runcommand return checkargs() File "/usr/local/Cellar/mercurial/2.2.2/libexec/mercurial/dispatch.py", line 757, in checkargs return cmdfunc() File "/usr/local/Cellar/mercurial/2.2.2/libexec/mercurial/dispatch.py", line 693, in d = lambda: util.checksignature(func)(ui, *args, **cmdoptions) File "/usr/local/Cellar/mercurial/2.2.2/libexec/mercurial/util.py", line 463, in check return func(*args, **kwargs) File "/usr/local/Cellar/mercurial/2.2.2/libexec/hgext/mq.py", line 2953, in select not q.pushable(i)[0]] File "/usr/local/Cellar/mercurial/2.2.2/libexec/hgext/mq.py", line 487, in pushable patchguards = self.seriesguards[idx] IndexError: list index out of range From stephen.bannasch at deanbrook.org Sun Jul 15 15:56:16 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sun, 15 Jul 2012 18:56:16 -0400 Subject: failure compiling coroutine.cpp when coro guard enabled Message-ID: I'm getting this error compiling coroutine.cpp when I add "coro" to my guards coroutine.cpp:111: error: 'startInternal_method_name' is not a member of 'vmSymbols' That's with these guards: export guards="buildable testable coro" This is on Mac OS X 10.6.8 and 10.7.4. MLVM builds and runs fine with just these guards: export guards="buildable testable" Using update.sh as a build script from: https://gist.github.com/243072 ** many updates to build script, supports arguments to script I now compile MLVM with coro like this: ./update.sh --coro Console output for both 10.6.8 and 10.7.4 here (different compilers used): https://gist.github.com/3118989 From john.r.rose at oracle.com Sun Jul 15 22:40:20 2012 From: john.r.rose at oracle.com (John Rose) Date: Sun, 15 Jul 2012 22:40:20 -0700 Subject: failure compiling coroutine.cpp when coro guard enabled In-Reply-To: References: Message-ID: On Jul 15, 2012, at 3:56 PM, Stephen Bannasch wrote: > I'm getting this error compiling coroutine.cpp when I add "coro" to my guards > > coroutine.cpp:111: error: 'startInternal_method_name' is not a member of 'vmSymbols' The problem is that the coro.patch file did not apply cleanly. A recent rebasing to hotspot-comp has probably broken the coro script. A relevant interfering change is this, in hotspot-comp: > changeset: 3281:0105f367a14c > user: rbackman > date: Tue Mar 06 12:36:59 2012 +0100 > summary: 7160570: Intrinsification support for tracing framework The script you use to apply the patches will have reported an error, something like this: > 1 out of 5 hunks FAILED -- saving rejects to file src/share/vm/classfile/vmSymbols.hpp.rej If the patches fail to apply, there is little or no hope that the build process will work. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120715/fc5cc595/attachment.html From john.r.rose at oracle.com Mon Jul 16 01:11:02 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Mon, 16 Jul 2012 08:11:02 +0000 Subject: hg: mlvm/mlvm/jdk: meth: improve debugging display of DMHs in backtraces Message-ID: <20120716081102.B930E4707E@hg.openjdk.java.net> Changeset: cec00d423fbc Author: jrose Date: 2012-07-16 01:10 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/cec00d423fbc meth: improve debugging display of DMHs in backtraces ! meth-lazy-7023639.bmh.patch From john.r.rose at oracle.com Mon Jul 16 01:12:08 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Mon, 16 Jul 2012 08:12:08 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: improve display of poly-sig method names -Xprof, -XX:+PrintCompilation Message-ID: <20120716081209.AD11B4707F@hg.openjdk.java.net> Changeset: a211c1a525fd Author: jrose Date: 2012-07-16 01:12 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a211c1a525fd meth: improve display of poly-sig method names -Xprof, -XX:+PrintCompilation ! meth-lazy-7023639.review.patch From forax at univ-mlv.fr Mon Jul 16 06:11:32 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 16 Jul 2012 15:11:32 +0200 Subject: Crash using sun.misc.Unsafe.static Message-ID: <50041304.2070703@univ-mlv.fr> Hi guys, the latest jdk6 (jdk6 update 33) fails hard in the compiler if I try to store the result of unsafe.staticFieldBase() in a static final field, i.e if it's considered as a constant. Neither recent jdk7 nor jdk8 crash, only jdk6 (it also failed with update 21 which is the oldest version I have). I think it doesn't crash with recent VM because the result of unsafe.staticFieldBase() is not a real object with jdk6 but is a real one with jdk7/jdk8 (because of permgen removal) Is this bug can be fixed or should I just do not do that ? cheers, R?mi package sun.misc; import java.lang.reflect.Field; public class UnsafeCrash { private static int value = 1; private static final Unsafe UNSAFE; private static final Object STATIC_FIELD_BASE; private static final long STATIC_FIELD_OFFSET; static { Field field; try { field = UnsafeCrash.class.getDeclaredField("value"); } catch (NoSuchFieldException e) { throw new AssertionError(e); } Unsafe unsafe = Unsafe.getUnsafe(); UNSAFE = unsafe; STATIC_FIELD_BASE = unsafe.staticFieldBase(field); STATIC_FIELD_OFFSET = unsafe.staticFieldOffset(field); } private static int test() { return UNSAFE.getInt(STATIC_FIELD_BASE, STATIC_FIELD_OFFSET); } public static void main(String[] args) { int sum = 0; for(int i=0; i<100000; i++) { sum += test(); } System.out.println(sum); } } [forax at localhost src]$ /usr/jdk/jdk1.6.0_33/bin/java -Xbootclasspath/p:. sun.misc.UnsafeCrash # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (type.cpp:2520), pid=26155, tid=139712055437056 # Error: ShouldNotReachHere() [thread 139712054384384 also had an error]# # JRE version: 6.0_33-b04 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.8-b03 mixed mode linux-amd64 compressed oops) # An error report file with more information is saved as: # /home/forax/java/workspace/java-blog/src/hs_err_pid26155.log 100000 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (type.cpp:2520), pid=26155, tid=139712055437056 # Error: ShouldNotReachHere() # # JRE version: 6.0_33-b04 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.8-b03 mixed mode linux-amd64 compressed oops) # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00007f1160093800): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=26169, stack(0x00007f113f5f6000,0x00007f113f6f7000)] Stack: [0x00007f113f5f6000,0x00007f113f6f7000], sp=0x00007f113f6f3860, free space=1014k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x85f725] VMError::report_and_die()+0x265 V [libjvm.so+0x3e4dd6] report_should_not_reach_here(char const*, int)+0x46 V [libjvm.so+0x830041] TypeOopPtr::make_from_constant(ciObject*, bool)+0x2a1 V [libjvm.so+0x73bcd5] Parse::push_constant(ciConstant, bool)+0x385 V [libjvm.so+0x73b628] Parse::do_get_xxx(TypePtr const*, Node*, ciField*, bool)+0x3e8 V [libjvm.so+0x73b152] Parse::do_field_access(bool, bool)+0x142 V [libjvm.so+0x73a926] Parse::do_one_bytecode()+0x68d6 V [libjvm.so+0x72b07a] Parse::do_one_block()+0x1aa V [libjvm.so+0x728ad0] Parse::do_all_blocks()+0x150 V [libjvm.so+0x72860b] Parse::Parse(JVMState*, ciMethod*, float)+0x59b V [libjvm.so+0x322064] ParseGenerator::generate(JVMState*)+0x84 V [libjvm.so+0x39e7e2] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool)+0x762 V [libjvm.so+0x3217de] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x9e V [libjvm.so+0x3a914a] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x2ca V [libjvm.so+0x3a8a35] CompileBroker::compiler_thread_loop()+0x355 V [libjvm.so+0x8208c9] compiler_thread_entry(JavaThread*, Thread*)+0x9 V [libjvm.so+0x819dd1] JavaThread::run()+0x121 V [libjvm.so+0x7117af] java_start(Thread*)+0x13f Current CompileTask: C2: 57 1 sun.misc.UnsafeCrash.test()I (13 bytes) --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x00007f1160098800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=26171, stack(0x00007f113f3f4000,0x00007f113f4f5000)] 0x00007f1160096000 JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=26170, stack(0x00007f113f4f5000,0x00007f113f5f6000)] =>0x00007f1160093800 JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=26169, stack(0x00007f113f5f6000,0x00007f113f6f7000)] 0x00007f1160091000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=26168, stack(0x00007f113f6f7000,0x00007f113f7f8000)] 0x00007f1160074800 JavaThread "Finalizer" daemon [_thread_blocked, id=26167, stack(0x00007f113f7f8000,0x00007f113f8f9000)] 0x00007f1160072800 JavaThread "Reference Handler" daemon [_thread_blocked, id=26166, stack(0x00007f113f8f9000,0x00007f113f9fa000)] 0x00007f1160006800 JavaThread "main" [_thread_in_native_trans, id=26156, stack(0x00007f1164c12000,0x00007f1164d13000)] Other Threads: 0x00007f116006c000 VMThread [stack: 0x00007f113f9fa000,0x00007f113fafb000] [id=26165] 0x00007f11600ab000 WatcherThread [stack: 0x00007f113f2f3000,0x00007f113f3f4000] [id=26172] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap PSYoungGen total 36992K, used 634K [0x00000007d6b60000, 0x00000007d94a0000, 0x0000000800000000) eden space 31744K, 2% used [0x00000007d6b60000,0x00000007d6bfeb90,0x00000007d8a60000) from space 5248K, 0% used [0x00000007d8f80000,0x00000007d8f80000,0x00000007d94a0000) to space 5248K, 0% used [0x00000007d8a60000,0x00000007d8a60000,0x00000007d8f80000) PSOldGen total 84544K, used 0K [0x0000000784200000, 0x0000000789490000, 0x00000007d6b60000) object space 84544K, 0% used [0x0000000784200000,0x0000000784200000,0x0000000789490000) PSPermGen total 21248K, used 2318K [0x000000077f000000, 0x00000007804c0000, 0x0000000784200000) object space 21248K, 10% used [0x000000077f000000,0x000000077f243b48,0x00000007804c0000) Code Cache [0x00007f115d000000, 0x00007f115d270000, 0x00007f1160000000) total_blobs=164 nmethods=1 adapters=118 free_code_cache=49949696 largest_free_block=11392 Dynamic libraries: 40000000-40009000 r-xp 00000000 fd:00 1317646 /usr/jdk/jdk1.6.0_33/bin/java 40108000-4010a000 rwxp 00008000 fd:00 1317646 /usr/jdk/jdk1.6.0_33/bin/java 40df5000-40e16000 rwxp 00000000 00:00 0 [heap] 77f000000-7804c0000 rwxp 00000000 00:00 0 7804c0000-784200000 rwxp 00000000 00:00 0 784200000-789490000 rwxp 00000000 00:00 0 789490000-7d6b60000 rwxp 00000000 00:00 0 7d6b60000-7d94a0000 rwxp 00000000 00:00 0 7d94a0000-800000000 rwxp 00000000 00:00 0 370bc00000-370bc20000 r-xp 00000000 fd:00 524413 /usr/lib64/ld-2.15.so 370be1f000-370be20000 r-xp 0001f000 fd:00 524413 /usr/lib64/ld-2.15.so 370be20000-370be21000 rwxp 00020000 fd:00 524413 /usr/lib64/ld-2.15.so 370be21000-370be22000 rwxp 00000000 00:00 0 370c000000-370c1ac000 r-xp 00000000 fd:00 524461 /usr/lib64/libc-2.15.so 370c1ac000-370c3ac000 ---p 001ac000 fd:00 524461 /usr/lib64/libc-2.15.so 370c3ac000-370c3b0000 r-xp 001ac000 fd:00 524461 /usr/lib64/libc-2.15.so 370c3b0000-370c3b2000 rwxp 001b0000 fd:00 524461 /usr/lib64/libc-2.15.so 370c3b2000-370c3b7000 rwxp 00000000 00:00 0 370c400000-370c416000 r-xp 00000000 fd:00 524491 /usr/lib64/libpthread-2.15.so 370c416000-370c616000 ---p 00016000 fd:00 524491 /usr/lib64/libpthread-2.15.so 370c616000-370c617000 r-xp 00016000 fd:00 524491 /usr/lib64/libpthread-2.15.so 370c617000-370c618000 rwxp 00017000 fd:00 524491 /usr/lib64/libpthread-2.15.so 370c618000-370c61c000 rwxp 00000000 00:00 0 370c800000-370c8fa000 r-xp 00000000 fd:00 524518 /usr/lib64/libm-2.15.so 370c8fa000-370caf9000 ---p 000fa000 fd:00 524518 /usr/lib64/libm-2.15.so 370caf9000-370cafa000 r-xp 000f9000 fd:00 524518 /usr/lib64/libm-2.15.so 370cafa000-370cafb000 rwxp 000fa000 fd:00 524518 /usr/lib64/libm-2.15.so 370cc00000-370cc03000 r-xp 00000000 fd:00 524561 /usr/lib64/libdl-2.15.so 370cc03000-370ce02000 ---p 00003000 fd:00 524561 /usr/lib64/libdl-2.15.so 370ce02000-370ce03000 r-xp 00002000 fd:00 524561 /usr/lib64/libdl-2.15.so 370ce03000-370ce04000 rwxp 00003000 fd:00 524561 /usr/lib64/libdl-2.15.so 370d000000-370d007000 r-xp 00000000 fd:00 524659 /usr/lib64/librt-2.15.so 370d007000-370d206000 ---p 00007000 fd:00 524659 /usr/lib64/librt-2.15.so 370d206000-370d207000 r-xp 00006000 fd:00 524659 /usr/lib64/librt-2.15.so 370d207000-370d208000 rwxp 00007000 fd:00 524659 /usr/lib64/librt-2.15.so 3720c00000-3720c16000 r-xp 00000000 fd:00 525403 /usr/lib64/libnsl-2.15.so 3720c16000-3720e15000 ---p 00016000 fd:00 525403 /usr/lib64/libnsl-2.15.so 3720e15000-3720e16000 r-xp 00015000 fd:00 525403 /usr/lib64/libnsl-2.15.so 3720e16000-3720e17000 rwxp 00016000 fd:00 525403 /usr/lib64/libnsl-2.15.so 3720e17000-3720e19000 rwxp 00000000 00:00 0 7f1110000000-7f1110021000 rwxp 00000000 00:00 0 7f1110021000-7f1114000000 ---p 00000000 00:00 0 7f1114000000-7f1114021000 rwxp 00000000 00:00 0 7f1114021000-7f1118000000 ---p 00000000 00:00 0 7f1118000000-7f111805c000 rwxp 00000000 00:00 0 7f111805c000-7f111c000000 ---p 00000000 00:00 0 7f111c000000-7f111c021000 rwxp 00000000 00:00 0 7f111c021000-7f1120000000 ---p 00000000 00:00 0 7f1120000000-7f1120021000 rwxp 00000000 00:00 0 7f1120021000-7f1124000000 ---p 00000000 00:00 0 7f1125bd3000-7f112c000000 r-xp 00000000 fd:00 928733 /usr/lib/locale/locale-archive 7f112c000000-7f112c021000 rwxp 00000000 00:00 0 7f112c021000-7f1130000000 ---p 00000000 00:00 0 7f1130000000-7f1130021000 rwxp 00000000 00:00 0 7f1130021000-7f1134000000 ---p 00000000 00:00 0 7f1134000000-7f1134021000 rwxp 00000000 00:00 0 7f1134021000-7f1138000000 ---p 00000000 00:00 0 7f1138000000-7f1138021000 rwxp 00000000 00:00 0 7f1138021000-7f113c000000 ---p 00000000 00:00 0 7f113f2f3000-7f113f2f4000 ---p 00000000 00:00 0 7f113f2f4000-7f113f3f4000 rwxp 00000000 00:00 0 [stack:26172] 7f113f3f4000-7f113f3f7000 ---p 00000000 00:00 0 7f113f3f7000-7f113f4f5000 rwxp 00000000 00:00 0 [stack:26171] 7f113f4f5000-7f113f4f8000 ---p 00000000 00:00 0 7f113f4f8000-7f113f5f6000 rwxp 00000000 00:00 0 [stack:26170] 7f113f5f6000-7f113f5f9000 ---p 00000000 00:00 0 7f113f5f9000-7f113f6f7000 rwxp 00000000 00:00 0 [stack:26169] 7f113f6f7000-7f113f6fa000 ---p 00000000 00:00 0 7f113f6fa000-7f113f7f8000 rwxp 00000000 00:00 0 [stack:26168] 7f113f7f8000-7f113f7fb000 ---p 00000000 00:00 0 7f113f7fb000-7f113f8f9000 rwxp 00000000 00:00 0 [stack:26167] 7f113f8f9000-7f113f8fc000 ---p 00000000 00:00 0 7f113f8fc000-7f113f9fa000 rwxp 00000000 00:00 0 [stack:26166] 7f113f9fa000-7f113f9fb000 ---p 00000000 00:00 0 7f113f9fb000-7f1140000000 rwxp 00000000 00:00 0 [stack:26165] 7f1140000000-7f1140021000 rwxp 00000000 00:00 0 7f1140021000-7f1144000000 ---p 00000000 00:00 0 7f1144000000-7f1144021000 rwxp 00000000 00:00 0 7f1144021000-7f1148000000 ---p 00000000 00:00 0 7f1148000000-7f1148021000 rwxp 00000000 00:00 0 7f1148021000-7f114c000000 ---p 00000000 00:00 0 7f114c000000-7f114c021000 rwxp 00000000 00:00 0 7f114c021000-7f1150000000 ---p 00000000 00:00 0 7f1150000000-7f1150021000 rwxp 00000000 00:00 0 7f1150021000-7f1154000000 ---p 00000000 00:00 0 7f1154000000-7f1154021000 rwxp 00000000 00:00 0 7f1154021000-7f1158000000 ---p 00000000 00:00 0 7f1158000000-7f1158021000 rwxp 00000000 00:00 0 7f1158021000-7f115c000000 ---p 00000000 00:00 0 7f115c0c9000-7f115c4cd000 rwxp 00000000 00:00 0 7f115c4cd000-7f115c664000 r-xs 0307a000 fd:00 1451207 /usr/jdk/jdk1.6.0_33/jre/lib/rt.jar 7f115c664000-7f115c665000 ---p 00000000 00:00 0 7f115c665000-7f115c765000 rwxp 00000000 00:00 0 [stack:26164] 7f115c765000-7f115c766000 ---p 00000000 00:00 0 7f115c766000-7f115c866000 rwxp 00000000 00:00 0 [stack:26163] 7f115c866000-7f115c867000 ---p 00000000 00:00 0 7f115c867000-7f115c967000 rwxp 00000000 00:00 0 [stack:26162] 7f115c967000-7f115c968000 ---p 00000000 00:00 0 7f115c968000-7f115ca68000 rwxp 00000000 00:00 0 [stack:26161] 7f115ca68000-7f115ca69000 ---p 00000000 00:00 0 7f115ca69000-7f115cb69000 rwxp 00000000 00:00 0 [stack:26160] 7f115cb69000-7f115cb6a000 ---p 00000000 00:00 0 7f115cb6a000-7f115cc6a000 rwxp 00000000 00:00 0 [stack:26159] 7f115cc6a000-7f115cc6b000 ---p 00000000 00:00 0 7f115cc6b000-7f115cd95000 rwxp 00000000 00:00 0 [stack:26158] 7f115cd95000-7f115d000000 rwxp 00000000 00:00 0 7f115d000000-7f115d270000 rwxp 00000000 00:00 0 7f115d270000-7f11600ad000 rwxp 00000000 00:00 0 7f11600ad000-7f1164000000 ---p 00000000 00:00 0 7f1164043000-7f116409f000 rwxp 00000000 00:00 0 7f116409f000-7f11640a0000 ---p 00000000 00:00 0 7f11640a0000-7f11641ab000 rwxp 00000000 00:00 0 [stack:26157] 7f11641ab000-7f11641c9000 rwxp 00000000 00:00 0 7f11641c9000-7f11641d4000 rwxp 00000000 00:00 0 7f11641d4000-7f11641f2000 rwxp 00000000 00:00 0 7f11641f2000-7f116421c000 rwxp 00000000 00:00 0 7f116421c000-7f1164486000 rwxp 00000000 00:00 0 7f1164486000-7f116449c000 rwxp 00000000 00:00 0 7f116449c000-7f11645d1000 rwxp 00000000 00:00 0 7f11645d1000-7f11645dc000 rwxp 00000000 00:00 0 7f11645dc000-7f1164692000 rwxp 00000000 00:00 0 7f1164692000-7f11646a0000 r-xp 00000000 fd:00 1450497 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libzip.so 7f11646a0000-7f11647a2000 ---p 0000e000 fd:00 1450497 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libzip.so 7f11647a2000-7f11647a5000 rwxp 00010000 fd:00 1450497 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libzip.so 7f11647a5000-7f11647a6000 rwxp 00000000 00:00 0 7f11647a6000-7f11647b2000 r-xp 00000000 fd:00 541082 /usr/lib64/libnss_files-2.15.so 7f11647b2000-7f11649b1000 ---p 0000c000 fd:00 541082 /usr/lib64/libnss_files-2.15.so 7f11649b1000-7f11649b2000 r-xp 0000b000 fd:00 541082 /usr/lib64/libnss_files-2.15.so 7f11649b2000-7f11649b3000 rwxp 0000c000 fd:00 541082 /usr/lib64/libnss_files-2.15.so 7f11649cc000-7f11649d4000 rwxs 00000000 fd:00 787099 /tmp/hsperfdata_forax/26155 7f11649d4000-7f11649fd000 r-xp 00000000 fd:00 1450510 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libjava.so 7f11649fd000-7f1164afc000 ---p 00029000 fd:00 1450510 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libjava.so 7f1164afc000-7f1164b03000 rwxp 00028000 fd:00 1450510 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libjava.so 7f1164b03000-7f1164b10000 r-xp 00000000 fd:00 1450492 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libverify.so 7f1164b10000-7f1164c0f000 ---p 0000d000 fd:00 1450492 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libverify.so 7f1164c0f000-7f1164c12000 rwxp 0000c000 fd:00 1450492 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libverify.so 7f1164c12000-7f1164c15000 ---p 00000000 00:00 0 7f1164c15000-7f1164d13000 rwxp 00000000 00:00 0 [stack:26156] 7f1164d13000-7f116562e000 r-xp 00000000 fd:00 1450517 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/server/libjvm.so 7f116562e000-7f116572f000 ---p 0091b000 fd:00 1450517 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/server/libjvm.so 7f116572f000-7f11658e4000 rwxp 0091c000 fd:00 1450517 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/server/libjvm.so 7f11658e4000-7f1165921000 rwxp 00000000 00:00 0 7f1165921000-7f1165928000 r-xp 00000000 fd:00 1450482 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/jli/libjli.so 7f1165928000-7f1165a29000 ---p 00007000 fd:00 1450482 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/jli/libjli.so 7f1165a29000-7f1165a2b000 rwxp 00008000 fd:00 1450482 /usr/jdk/jdk1.6.0_33/jre/lib/amd64/jli/libjli.so 7f1165a2b000-7f1165a2c000 rwxp 00000000 00:00 0 7f1165a4b000-7f1165a4c000 rwxp 00000000 00:00 0 7f1165a4c000-7f1165a4d000 r-xp 00000000 00:00 0 7f1165a4d000-7f1165a4e000 rwxp 00000000 00:00 0 7fff12b9a000-7fff12bbb000 rwxp 00000000 00:00 0 [stack] 7fff12bff000-7fff12c00000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] VM Arguments: jvm_args: -Xbootclasspath/p:. java_command: sun.misc.UnsafeCrash Launcher Type: SUN_STANDARD Environment Variables: JAVA_HOME=/usr/java PATH=/home/forax/bin:/usr/java/bin:ANT_HOME/bin:/home/forax/bin:/usr/java/bin:ANT_HOME/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:.:/home/forax/bin:. USERNAME=forax LD_LIBRARY_PATH=/usr/jdk/jdk1.6.0_33/jre/lib/amd64/server:/usr/jdk/jdk1.6.0_33/jre/lib/amd64:/usr/jdk/jdk1.6.0_33/jre/../lib/amd64 SHELL=/bin/bash DISPLAY=:0 Signal Handlers: SIGSEGV: [libjvm.so+0x860350], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGBUS: [libjvm.so+0x860350], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGFPE: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGPIPE: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGXFSZ: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGILL: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 SIGUSR2: [libjvm.so+0x711de0], sa_mask[0]=0x00000000, sa_flags=0x10000004 SIGHUP: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGINT: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGTERM: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGQUIT: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 --------------- S Y S T E M --------------- OS:Fedora release 17 (Beefy Miracle) uname:Linux 3.4.4-5.fc17.x86_64 #1 SMP Thu Jul 5 20:20:59 UTC 2012 x86_64 libc:glibc 2.15 NPTL 2.15 rlimit: STACK 8192k, CORE 0k, NPROC 1024, NOFILE 4096, AS infinity load average:0.66 0.84 0.86 /proc/meminfo: MemTotal: 8111160 kB MemFree: 2707952 kB Buffers: 403496 kB Cached: 2287500 kB SwapCached: 0 kB Active: 3194044 kB Inactive: 1702076 kB Active(anon): 2209972 kB Inactive(anon): 4480 kB Active(file): 984072 kB Inactive(file): 1697596 kB Unevictable: 3512 kB Mlocked: 3512 kB SwapTotal: 10223612 kB SwapFree: 10223612 kB Dirty: 116 kB Writeback: 0 kB AnonPages: 2202480 kB Mapped: 240744 kB Shmem: 7068 kB Slab: 261100 kB SReclaimable: 224240 kB SUnreclaim: 36860 kB KernelStack: 4512 kB PageTables: 38108 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 14279192 kB Committed_AS: 4654596 kB VmallocTotal: 34359738367 kB VmallocUsed: 169372 kB VmallocChunk: 34359555724 kB HardwareCorrupted: 0 kB AnonHugePages: 1294336 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 387452 kB DirectMap2M: 7933952 kB CPU:total 8 (4 cores per cpu, 2 threads per core) family 6 model 30 stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, ht /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz stepping : 5 microcode : 0x5 cpu MHz : 1199.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips : 3724.10 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz stepping : 5 microcode : 0x5 cpu MHz : 1199.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips : 3724.10 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz stepping : 5 microcode : 0x5 cpu MHz : 1199.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips : 3724.10 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz stepping : 5 microcode : 0x5 cpu MHz : 1199.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 6 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips : 3724.10 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 4 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz stepping : 5 microcode : 0x5 cpu MHz : 1199.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips : 3724.10 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 5 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz stepping : 5 microcode : 0x5 cpu MHz : 1867.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 1 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips : 3724.10 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 6 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz stepping : 5 microcode : 0x5 cpu MHz : 1867.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 2 cpu cores : 4 apicid : 5 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips : 3724.10 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 30 model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz stepping : 5 microcode : 0x5 cpu MHz : 1199.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 3 cpu cores : 4 apicid : 7 initial apicid : 7 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid bogomips : 3724.10 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Memory: 4k page, physical 8111160k(2707952k free), swap 10223612k(10223612k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (20.8-b03) for linux-amd64 JRE (1.6.0_33-b04), built on Jun 21 2012 16:28:12 by "java_re" with gcc 3.2.2 (SuSE Linux) time: Mon Jul 16 14:57:38 2012 elapsed time: 0 seconds From christian.thalinger at oracle.com Mon Jul 16 12:36:11 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 16 Jul 2012 12:36:11 -0700 Subject: hg: mlvm/mlvm/jdk: meth: performance work In-Reply-To: <20120715010250.BCC604704F@hg.openjdk.java.net> References: <20120715010250.BCC604704F@hg.openjdk.java.net> Message-ID: On Jul 14, 2012, at 6:02 PM, john.r.rose at oracle.com wrote: > Changeset: 56879e348afe > Author: jrose > Date: 2012-07-14 18:02 -0700 > URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/56879e348afe > > meth: performance work > > + meth-lazy-7023639.bmh.patch > + meth-lazy-7023639.init.patch Somehow this patch prevents compilation(?) of LFs and we always run in the LF interpreter: @ 20 java.lang.invoke.LambdaForm$MH007/1350355205::linkToCallSite (18 bytes) inline (hot) @ 1 java.lang.invoke.Invokers::getCallSiteTarget (8 bytes) inline (hot) @ 4 java.lang.invoke.MutableCallSite::getTarget (5 bytes) inline (hot) @ 14 java.lang.invoke.LambdaForm$LFI005/1770098351::interpret_L (29 bytes) inline (hot) @ 25 java.lang.invoke.LambdaForm::interpretWithArguments (124 bytes) inline (hot) ! @ 41 java.lang.invoke.LambdaForm::compileToBytecode (95 bytes) too big @ 53 java.lang.invoke.LambdaForm::arityCheck (130 bytes) inline (hot) @ 113 java.lang.invoke.MethodHandle::internalForm (5 bytes) inline (hot) @ 73 java.util.Arrays::copyOf (13 bytes) inline (hot) @ 3 java.lang.Object::getClass (0 bytes) (intrinsic) @ 6 java.util.Arrays::copyOf (47 bytes) (intrinsic) @ 96 java.lang.invoke.LambdaForm::interpretName (122 bytes) already compiled into a big method Haven't figured out what the exact problem is. -- Chris > ! series > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From rednaxelafx at gmail.com Mon Jul 16 16:06:54 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 17 Jul 2012 07:06:54 +0800 Subject: Crash using sun.misc.Unsafe.static In-Reply-To: <50041304.2070703@univ-mlv.fr> References: <50041304.2070703@univ-mlv.fr> Message-ID: Hi Remi, Looks like it's a trap if you're running this on JDK6's HotSpot VM. If you're running a debug build of the same VM, you should hit an assertion before hitting the ShouldNotReachHere() part. opto/type.cpp:2477 assert(o->is_java_object(), "must be java language object"); Even though the source code of JDK6u33 is not open sourced, you could try a similar version of HotSpot VM from OpenJDK, namely the hsx/hsx20/baseline branch, or jdk6/jdk6/hotspot. Make a fastdebug build and you should see the assertion. And you're right that this has to do with the PermGen removal project. The difference comes from [1], which is a part of CR 7017732. To be specific, before the 7017732, static fields are stored in the instanceKlass of a Java class; an instanceKlass (or its enclosing klassOopDesc to be exact) is not an Java object. After 7017732, static fields are moved to the tail of java.lang.Class instances, which are Java objects. So to answer your question, you just shouldn't expect the the code to work in JDK6/HotSpot. [1]: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/diff/c7f3d0b4570f/src/share/vm/prims/unsafe.cpp On Mon, Jul 16, 2012 at 9:11 PM, R?mi Forax wrote: > Hi guys, > the latest jdk6 (jdk6 update 33) fails hard in the compiler if I try to > store the result of unsafe.staticFieldBase() in > a static final field, i.e if it's considered as a constant. > Neither recent jdk7 nor jdk8 crash, only jdk6 (it also failed with > update 21 which is the oldest version I have). > > I think it doesn't crash with recent VM because the result of > unsafe.staticFieldBase() is not a real object > with jdk6 but is a real one with jdk7/jdk8 (because of permgen removal) > > Is this bug can be fixed or should I just do not do that ? > > cheers, > R?mi > > package sun.misc; > > import java.lang.reflect.Field; > > public class UnsafeCrash { > private static int value = 1; > > private static final Unsafe UNSAFE; > private static final Object STATIC_FIELD_BASE; > private static final long STATIC_FIELD_OFFSET; > > static { > Field field; > try { > field = UnsafeCrash.class.getDeclaredField("value"); > } catch (NoSuchFieldException e) { > throw new AssertionError(e); > } > Unsafe unsafe = Unsafe.getUnsafe(); > UNSAFE = unsafe; > STATIC_FIELD_BASE = unsafe.staticFieldBase(field); > STATIC_FIELD_OFFSET = unsafe.staticFieldOffset(field); > } > > private static int test() { > return UNSAFE.getInt(STATIC_FIELD_BASE, STATIC_FIELD_OFFSET); > } > > public static void main(String[] args) { > int sum = 0; > for(int i=0; i<100000; i++) { > sum += test(); > } > System.out.println(sum); > } > } > > > [forax at localhost src]$ /usr/jdk/jdk1.6.0_33/bin/java -Xbootclasspath/p:. > sun.misc.UnsafeCrash > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (type.cpp:2520), pid=26155, tid=139712055437056 > # Error: ShouldNotReachHere() > [thread 139712054384384 also had an error]# > > # JRE version: 6.0_33-b04 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.8-b03 mixed mode > linux-amd64 compressed oops) > # An error report file with more information is saved as: > # /home/forax/java/workspace/java-blog/src/hs_err_pid26155.log > 100000 > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (type.cpp:2520), pid=26155, tid=139712055437056 > # Error: ShouldNotReachHere() > # > # JRE version: 6.0_33-b04 > # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.8-b03 mixed mode > linux-amd64 compressed oops) > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00007f1160093800): JavaThread "C2 CompilerThread0" > daemon [_thread_in_native, id=26169, > stack(0x00007f113f5f6000,0x00007f113f6f7000)] > > Stack: [0x00007f113f5f6000,0x00007f113f6f7000], sp=0x00007f113f6f3860, > free space=1014k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0x85f725] VMError::report_and_die()+0x265 > V [libjvm.so+0x3e4dd6] report_should_not_reach_here(char const*, > int)+0x46 > V [libjvm.so+0x830041] TypeOopPtr::make_from_constant(ciObject*, > bool)+0x2a1 > V [libjvm.so+0x73bcd5] Parse::push_constant(ciConstant, bool)+0x385 > V [libjvm.so+0x73b628] Parse::do_get_xxx(TypePtr const*, Node*, > ciField*, bool)+0x3e8 > V [libjvm.so+0x73b152] Parse::do_field_access(bool, bool)+0x142 > V [libjvm.so+0x73a926] Parse::do_one_bytecode()+0x68d6 > V [libjvm.so+0x72b07a] Parse::do_one_block()+0x1aa > V [libjvm.so+0x728ad0] Parse::do_all_blocks()+0x150 > V [libjvm.so+0x72860b] Parse::Parse(JVMState*, ciMethod*, float)+0x59b > V [libjvm.so+0x322064] ParseGenerator::generate(JVMState*)+0x84 > V [libjvm.so+0x39e7e2] Compile::Compile(ciEnv*, C2Compiler*, > ciMethod*, int, bool, bool)+0x762 > V [libjvm.so+0x3217de] C2Compiler::compile_method(ciEnv*, ciMethod*, > int)+0x9e > V [libjvm.so+0x3a914a] > CompileBroker::invoke_compiler_on_method(CompileTask*)+0x2ca > V [libjvm.so+0x3a8a35] CompileBroker::compiler_thread_loop()+0x355 > V [libjvm.so+0x8208c9] compiler_thread_entry(JavaThread*, Thread*)+0x9 > V [libjvm.so+0x819dd1] JavaThread::run()+0x121 > V [libjvm.so+0x7117af] java_start(Thread*)+0x13f > > > Current CompileTask: > C2: 57 1 sun.misc.UnsafeCrash.test()I (13 bytes) > > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x00007f1160098800 JavaThread "Low Memory Detector" daemon > [_thread_blocked, id=26171, stack(0x00007f113f3f4000,0x00007f113f4f5000)] > 0x00007f1160096000 JavaThread "C2 CompilerThread1" daemon > [_thread_in_native, id=26170, stack(0x00007f113f4f5000,0x00007f113f5f6000)] > =>0x00007f1160093800 JavaThread "C2 CompilerThread0" daemon > [_thread_in_native, id=26169, stack(0x00007f113f5f6000,0x00007f113f6f7000)] > 0x00007f1160091000 JavaThread "Signal Dispatcher" daemon > [_thread_blocked, id=26168, stack(0x00007f113f6f7000,0x00007f113f7f8000)] > 0x00007f1160074800 JavaThread "Finalizer" daemon [_thread_blocked, > id=26167, stack(0x00007f113f7f8000,0x00007f113f8f9000)] > 0x00007f1160072800 JavaThread "Reference Handler" daemon > [_thread_blocked, id=26166, stack(0x00007f113f8f9000,0x00007f113f9fa000)] > 0x00007f1160006800 JavaThread "main" [_thread_in_native_trans, > id=26156, stack(0x00007f1164c12000,0x00007f1164d13000)] > > Other Threads: > 0x00007f116006c000 VMThread [stack: > 0x00007f113f9fa000,0x00007f113fafb000] [id=26165] > 0x00007f11600ab000 WatcherThread [stack: > 0x00007f113f2f3000,0x00007f113f3f4000] [id=26172] > > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap > PSYoungGen total 36992K, used 634K [0x00000007d6b60000, > 0x00000007d94a0000, 0x0000000800000000) > eden space 31744K, 2% used > [0x00000007d6b60000,0x00000007d6bfeb90,0x00000007d8a60000) > from space 5248K, 0% used > [0x00000007d8f80000,0x00000007d8f80000,0x00000007d94a0000) > to space 5248K, 0% used > [0x00000007d8a60000,0x00000007d8a60000,0x00000007d8f80000) > PSOldGen total 84544K, used 0K [0x0000000784200000, > 0x0000000789490000, 0x00000007d6b60000) > object space 84544K, 0% used > [0x0000000784200000,0x0000000784200000,0x0000000789490000) > PSPermGen total 21248K, used 2318K [0x000000077f000000, > 0x00000007804c0000, 0x0000000784200000) > object space 21248K, 10% used > [0x000000077f000000,0x000000077f243b48,0x00000007804c0000) > > Code Cache [0x00007f115d000000, 0x00007f115d270000, 0x00007f1160000000) > total_blobs=164 nmethods=1 adapters=118 free_code_cache=49949696 > largest_free_block=11392 > > Dynamic libraries: > 40000000-40009000 r-xp 00000000 fd:00 1317646 > /usr/jdk/jdk1.6.0_33/bin/java > 40108000-4010a000 rwxp 00008000 fd:00 1317646 > /usr/jdk/jdk1.6.0_33/bin/java > 40df5000-40e16000 rwxp 00000000 00:00 0 > [heap] > 77f000000-7804c0000 rwxp 00000000 00:00 0 > 7804c0000-784200000 rwxp 00000000 00:00 0 > 784200000-789490000 rwxp 00000000 00:00 0 > 789490000-7d6b60000 rwxp 00000000 00:00 0 > 7d6b60000-7d94a0000 rwxp 00000000 00:00 0 > 7d94a0000-800000000 rwxp 00000000 00:00 0 > 370bc00000-370bc20000 r-xp 00000000 fd:00 524413 > /usr/lib64/ld-2.15.so > 370be1f000-370be20000 r-xp 0001f000 fd:00 524413 > /usr/lib64/ld-2.15.so > 370be20000-370be21000 rwxp 00020000 fd:00 524413 > /usr/lib64/ld-2.15.so > 370be21000-370be22000 rwxp 00000000 00:00 0 > 370c000000-370c1ac000 r-xp 00000000 fd:00 524461 > /usr/lib64/libc-2.15.so > 370c1ac000-370c3ac000 ---p 001ac000 fd:00 524461 > /usr/lib64/libc-2.15.so > 370c3ac000-370c3b0000 r-xp 001ac000 fd:00 524461 > /usr/lib64/libc-2.15.so > 370c3b0000-370c3b2000 rwxp 001b0000 fd:00 524461 > /usr/lib64/libc-2.15.so > 370c3b2000-370c3b7000 rwxp 00000000 00:00 0 > 370c400000-370c416000 r-xp 00000000 fd:00 524491 > /usr/lib64/libpthread-2.15.so > 370c416000-370c616000 ---p 00016000 fd:00 524491 > /usr/lib64/libpthread-2.15.so > 370c616000-370c617000 r-xp 00016000 fd:00 524491 > /usr/lib64/libpthread-2.15.so > 370c617000-370c618000 rwxp 00017000 fd:00 524491 > /usr/lib64/libpthread-2.15.so > 370c618000-370c61c000 rwxp 00000000 00:00 0 > 370c800000-370c8fa000 r-xp 00000000 fd:00 524518 > /usr/lib64/libm-2.15.so > 370c8fa000-370caf9000 ---p 000fa000 fd:00 524518 > /usr/lib64/libm-2.15.so > 370caf9000-370cafa000 r-xp 000f9000 fd:00 524518 > /usr/lib64/libm-2.15.so > 370cafa000-370cafb000 rwxp 000fa000 fd:00 524518 > /usr/lib64/libm-2.15.so > 370cc00000-370cc03000 r-xp 00000000 fd:00 524561 > /usr/lib64/libdl-2.15.so > 370cc03000-370ce02000 ---p 00003000 fd:00 524561 > /usr/lib64/libdl-2.15.so > 370ce02000-370ce03000 r-xp 00002000 fd:00 524561 > /usr/lib64/libdl-2.15.so > 370ce03000-370ce04000 rwxp 00003000 fd:00 524561 > /usr/lib64/libdl-2.15.so > 370d000000-370d007000 r-xp 00000000 fd:00 524659 > /usr/lib64/librt-2.15.so > 370d007000-370d206000 ---p 00007000 fd:00 524659 > /usr/lib64/librt-2.15.so > 370d206000-370d207000 r-xp 00006000 fd:00 524659 > /usr/lib64/librt-2.15.so > 370d207000-370d208000 rwxp 00007000 fd:00 524659 > /usr/lib64/librt-2.15.so > 3720c00000-3720c16000 r-xp 00000000 fd:00 525403 > /usr/lib64/libnsl-2.15.so > 3720c16000-3720e15000 ---p 00016000 fd:00 525403 > /usr/lib64/libnsl-2.15.so > 3720e15000-3720e16000 r-xp 00015000 fd:00 525403 > /usr/lib64/libnsl-2.15.so > 3720e16000-3720e17000 rwxp 00016000 fd:00 525403 > /usr/lib64/libnsl-2.15.so > 3720e17000-3720e19000 rwxp 00000000 00:00 0 > 7f1110000000-7f1110021000 rwxp 00000000 00:00 0 > 7f1110021000-7f1114000000 ---p 00000000 00:00 0 > 7f1114000000-7f1114021000 rwxp 00000000 00:00 0 > 7f1114021000-7f1118000000 ---p 00000000 00:00 0 > 7f1118000000-7f111805c000 rwxp 00000000 00:00 0 > 7f111805c000-7f111c000000 ---p 00000000 00:00 0 > 7f111c000000-7f111c021000 rwxp 00000000 00:00 0 > 7f111c021000-7f1120000000 ---p 00000000 00:00 0 > 7f1120000000-7f1120021000 rwxp 00000000 00:00 0 > 7f1120021000-7f1124000000 ---p 00000000 00:00 0 > 7f1125bd3000-7f112c000000 r-xp 00000000 fd:00 928733 > /usr/lib/locale/locale-archive > 7f112c000000-7f112c021000 rwxp 00000000 00:00 0 > 7f112c021000-7f1130000000 ---p 00000000 00:00 0 > 7f1130000000-7f1130021000 rwxp 00000000 00:00 0 > 7f1130021000-7f1134000000 ---p 00000000 00:00 0 > 7f1134000000-7f1134021000 rwxp 00000000 00:00 0 > 7f1134021000-7f1138000000 ---p 00000000 00:00 0 > 7f1138000000-7f1138021000 rwxp 00000000 00:00 0 > 7f1138021000-7f113c000000 ---p 00000000 00:00 0 > 7f113f2f3000-7f113f2f4000 ---p 00000000 00:00 0 > 7f113f2f4000-7f113f3f4000 rwxp 00000000 00:00 0 > [stack:26172] > 7f113f3f4000-7f113f3f7000 ---p 00000000 00:00 0 > 7f113f3f7000-7f113f4f5000 rwxp 00000000 00:00 0 > [stack:26171] > 7f113f4f5000-7f113f4f8000 ---p 00000000 00:00 0 > 7f113f4f8000-7f113f5f6000 rwxp 00000000 00:00 0 > [stack:26170] > 7f113f5f6000-7f113f5f9000 ---p 00000000 00:00 0 > 7f113f5f9000-7f113f6f7000 rwxp 00000000 00:00 0 > [stack:26169] > 7f113f6f7000-7f113f6fa000 ---p 00000000 00:00 0 > 7f113f6fa000-7f113f7f8000 rwxp 00000000 00:00 0 > [stack:26168] > 7f113f7f8000-7f113f7fb000 ---p 00000000 00:00 0 > 7f113f7fb000-7f113f8f9000 rwxp 00000000 00:00 0 > [stack:26167] > 7f113f8f9000-7f113f8fc000 ---p 00000000 00:00 0 > 7f113f8fc000-7f113f9fa000 rwxp 00000000 00:00 0 > [stack:26166] > 7f113f9fa000-7f113f9fb000 ---p 00000000 00:00 0 > 7f113f9fb000-7f1140000000 rwxp 00000000 00:00 0 > [stack:26165] > 7f1140000000-7f1140021000 rwxp 00000000 00:00 0 > 7f1140021000-7f1144000000 ---p 00000000 00:00 0 > 7f1144000000-7f1144021000 rwxp 00000000 00:00 0 > 7f1144021000-7f1148000000 ---p 00000000 00:00 0 > 7f1148000000-7f1148021000 rwxp 00000000 00:00 0 > 7f1148021000-7f114c000000 ---p 00000000 00:00 0 > 7f114c000000-7f114c021000 rwxp 00000000 00:00 0 > 7f114c021000-7f1150000000 ---p 00000000 00:00 0 > 7f1150000000-7f1150021000 rwxp 00000000 00:00 0 > 7f1150021000-7f1154000000 ---p 00000000 00:00 0 > 7f1154000000-7f1154021000 rwxp 00000000 00:00 0 > 7f1154021000-7f1158000000 ---p 00000000 00:00 0 > 7f1158000000-7f1158021000 rwxp 00000000 00:00 0 > 7f1158021000-7f115c000000 ---p 00000000 00:00 0 > 7f115c0c9000-7f115c4cd000 rwxp 00000000 00:00 0 > 7f115c4cd000-7f115c664000 r-xs 0307a000 fd:00 1451207 > /usr/jdk/jdk1.6.0_33/jre/lib/rt.jar > 7f115c664000-7f115c665000 ---p 00000000 00:00 0 > 7f115c665000-7f115c765000 rwxp 00000000 00:00 0 > [stack:26164] > 7f115c765000-7f115c766000 ---p 00000000 00:00 0 > 7f115c766000-7f115c866000 rwxp 00000000 00:00 0 > [stack:26163] > 7f115c866000-7f115c867000 ---p 00000000 00:00 0 > 7f115c867000-7f115c967000 rwxp 00000000 00:00 0 > [stack:26162] > 7f115c967000-7f115c968000 ---p 00000000 00:00 0 > 7f115c968000-7f115ca68000 rwxp 00000000 00:00 0 > [stack:26161] > 7f115ca68000-7f115ca69000 ---p 00000000 00:00 0 > 7f115ca69000-7f115cb69000 rwxp 00000000 00:00 0 > [stack:26160] > 7f115cb69000-7f115cb6a000 ---p 00000000 00:00 0 > 7f115cb6a000-7f115cc6a000 rwxp 00000000 00:00 0 > [stack:26159] > 7f115cc6a000-7f115cc6b000 ---p 00000000 00:00 0 > 7f115cc6b000-7f115cd95000 rwxp 00000000 00:00 0 > [stack:26158] > 7f115cd95000-7f115d000000 rwxp 00000000 00:00 0 > 7f115d000000-7f115d270000 rwxp 00000000 00:00 0 > 7f115d270000-7f11600ad000 rwxp 00000000 00:00 0 > 7f11600ad000-7f1164000000 ---p 00000000 00:00 0 > 7f1164043000-7f116409f000 rwxp 00000000 00:00 0 > 7f116409f000-7f11640a0000 ---p 00000000 00:00 0 > 7f11640a0000-7f11641ab000 rwxp 00000000 00:00 0 > [stack:26157] > 7f11641ab000-7f11641c9000 rwxp 00000000 00:00 0 > 7f11641c9000-7f11641d4000 rwxp 00000000 00:00 0 > 7f11641d4000-7f11641f2000 rwxp 00000000 00:00 0 > 7f11641f2000-7f116421c000 rwxp 00000000 00:00 0 > 7f116421c000-7f1164486000 rwxp 00000000 00:00 0 > 7f1164486000-7f116449c000 rwxp 00000000 00:00 0 > 7f116449c000-7f11645d1000 rwxp 00000000 00:00 0 > 7f11645d1000-7f11645dc000 rwxp 00000000 00:00 0 > 7f11645dc000-7f1164692000 rwxp 00000000 00:00 0 > 7f1164692000-7f11646a0000 r-xp 00000000 fd:00 1450497 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libzip.so > 7f11646a0000-7f11647a2000 ---p 0000e000 fd:00 1450497 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libzip.so > 7f11647a2000-7f11647a5000 rwxp 00010000 fd:00 1450497 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libzip.so > 7f11647a5000-7f11647a6000 rwxp 00000000 00:00 0 > 7f11647a6000-7f11647b2000 r-xp 00000000 fd:00 541082 > /usr/lib64/libnss_files-2.15.so > 7f11647b2000-7f11649b1000 ---p 0000c000 fd:00 541082 > /usr/lib64/libnss_files-2.15.so > 7f11649b1000-7f11649b2000 r-xp 0000b000 fd:00 541082 > /usr/lib64/libnss_files-2.15.so > 7f11649b2000-7f11649b3000 rwxp 0000c000 fd:00 541082 > /usr/lib64/libnss_files-2.15.so > 7f11649cc000-7f11649d4000 rwxs 00000000 fd:00 787099 > /tmp/hsperfdata_forax/26155 > 7f11649d4000-7f11649fd000 r-xp 00000000 fd:00 1450510 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libjava.so > 7f11649fd000-7f1164afc000 ---p 00029000 fd:00 1450510 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libjava.so > 7f1164afc000-7f1164b03000 rwxp 00028000 fd:00 1450510 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libjava.so > 7f1164b03000-7f1164b10000 r-xp 00000000 fd:00 1450492 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libverify.so > 7f1164b10000-7f1164c0f000 ---p 0000d000 fd:00 1450492 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libverify.so > 7f1164c0f000-7f1164c12000 rwxp 0000c000 fd:00 1450492 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/libverify.so > 7f1164c12000-7f1164c15000 ---p 00000000 00:00 0 > 7f1164c15000-7f1164d13000 rwxp 00000000 00:00 0 > [stack:26156] > 7f1164d13000-7f116562e000 r-xp 00000000 fd:00 1450517 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/server/libjvm.so > 7f116562e000-7f116572f000 ---p 0091b000 fd:00 1450517 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/server/libjvm.so > 7f116572f000-7f11658e4000 rwxp 0091c000 fd:00 1450517 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/server/libjvm.so > 7f11658e4000-7f1165921000 rwxp 00000000 00:00 0 > 7f1165921000-7f1165928000 r-xp 00000000 fd:00 1450482 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/jli/libjli.so > 7f1165928000-7f1165a29000 ---p 00007000 fd:00 1450482 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/jli/libjli.so > 7f1165a29000-7f1165a2b000 rwxp 00008000 fd:00 1450482 > /usr/jdk/jdk1.6.0_33/jre/lib/amd64/jli/libjli.so > 7f1165a2b000-7f1165a2c000 rwxp 00000000 00:00 0 > 7f1165a4b000-7f1165a4c000 rwxp 00000000 00:00 0 > 7f1165a4c000-7f1165a4d000 r-xp 00000000 00:00 0 > 7f1165a4d000-7f1165a4e000 rwxp 00000000 00:00 0 > 7fff12b9a000-7fff12bbb000 rwxp 00000000 00:00 0 > [stack] > 7fff12bff000-7fff12c00000 r-xp 00000000 00:00 0 > [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 > [vsyscall] > > VM Arguments: > jvm_args: -Xbootclasspath/p:. > java_command: sun.misc.UnsafeCrash > Launcher Type: SUN_STANDARD > > Environment Variables: > JAVA_HOME=/usr/java > > PATH=/home/forax/bin:/usr/java/bin:ANT_HOME/bin:/home/forax/bin:/usr/java/bin:ANT_HOME/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:.:/home/forax/bin:. > USERNAME=forax > > LD_LIBRARY_PATH=/usr/jdk/jdk1.6.0_33/jre/lib/amd64/server:/usr/jdk/jdk1.6.0_33/jre/lib/amd64:/usr/jdk/jdk1.6.0_33/jre/../lib/amd64 > SHELL=/bin/bash > DISPLAY=:0 > > Signal Handlers: > SIGSEGV: [libjvm.so+0x860350], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGBUS: [libjvm.so+0x860350], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGFPE: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGPIPE: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGXFSZ: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGILL: [libjvm.so+0x70efb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 > SIGUSR2: [libjvm.so+0x711de0], sa_mask[0]=0x00000000, sa_flags=0x10000004 > SIGHUP: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGINT: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGTERM: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGQUIT: [libjvm.so+0x7119e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > > > --------------- S Y S T E M --------------- > > OS:Fedora release 17 (Beefy Miracle) > > uname:Linux 3.4.4-5.fc17.x86_64 #1 SMP Thu Jul 5 20:20:59 UTC 2012 x86_64 > libc:glibc 2.15 NPTL 2.15 > rlimit: STACK 8192k, CORE 0k, NPROC 1024, NOFILE 4096, AS infinity > load average:0.66 0.84 0.86 > > /proc/meminfo: > MemTotal: 8111160 kB > MemFree: 2707952 kB > Buffers: 403496 kB > Cached: 2287500 kB > SwapCached: 0 kB > Active: 3194044 kB > Inactive: 1702076 kB > Active(anon): 2209972 kB > Inactive(anon): 4480 kB > Active(file): 984072 kB > Inactive(file): 1697596 kB > Unevictable: 3512 kB > Mlocked: 3512 kB > SwapTotal: 10223612 kB > SwapFree: 10223612 kB > Dirty: 116 kB > Writeback: 0 kB > AnonPages: 2202480 kB > Mapped: 240744 kB > Shmem: 7068 kB > Slab: 261100 kB > SReclaimable: 224240 kB > SUnreclaim: 36860 kB > KernelStack: 4512 kB > PageTables: 38108 kB > NFS_Unstable: 0 kB > Bounce: 0 kB > WritebackTmp: 0 kB > CommitLimit: 14279192 kB > Committed_AS: 4654596 kB > VmallocTotal: 34359738367 kB > VmallocUsed: 169372 kB > VmallocChunk: 34359555724 kB > HardwareCorrupted: 0 kB > AnonHugePages: 1294336 kB > HugePages_Total: 0 > HugePages_Free: 0 > HugePages_Rsvd: 0 > HugePages_Surp: 0 > Hugepagesize: 2048 kB > DirectMap4k: 387452 kB > DirectMap2M: 7933952 kB > > > CPU:total 8 (4 cores per cpu, 2 threads per core) family 6 model 30 > stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, > sse4.2, popcnt, ht > > /proc/cpuinfo: > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 30 > model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz > stepping : 5 > microcode : 0x5 > cpu MHz : 1199.000 > cache size : 8192 KB > physical id : 0 > siblings : 8 > core id : 0 > cpu cores : 4 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 11 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall > nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 > cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi > flexpriority ept vpid > bogomips : 3724.10 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > processor : 1 > vendor_id : GenuineIntel > cpu family : 6 > model : 30 > model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz > stepping : 5 > microcode : 0x5 > cpu MHz : 1199.000 > cache size : 8192 KB > physical id : 0 > siblings : 8 > core id : 1 > cpu cores : 4 > apicid : 2 > initial apicid : 2 > fpu : yes > fpu_exception : yes > cpuid level : 11 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall > nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 > cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi > flexpriority ept vpid > bogomips : 3724.10 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > processor : 2 > vendor_id : GenuineIntel > cpu family : 6 > model : 30 > model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz > stepping : 5 > microcode : 0x5 > cpu MHz : 1199.000 > cache size : 8192 KB > physical id : 0 > siblings : 8 > core id : 2 > cpu cores : 4 > apicid : 4 > initial apicid : 4 > fpu : yes > fpu_exception : yes > cpuid level : 11 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall > nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 > cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi > flexpriority ept vpid > bogomips : 3724.10 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > processor : 3 > vendor_id : GenuineIntel > cpu family : 6 > model : 30 > model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz > stepping : 5 > microcode : 0x5 > cpu MHz : 1199.000 > cache size : 8192 KB > physical id : 0 > siblings : 8 > core id : 3 > cpu cores : 4 > apicid : 6 > initial apicid : 6 > fpu : yes > fpu_exception : yes > cpuid level : 11 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall > nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 > cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi > flexpriority ept vpid > bogomips : 3724.10 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > processor : 4 > vendor_id : GenuineIntel > cpu family : 6 > model : 30 > model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz > stepping : 5 > microcode : 0x5 > cpu MHz : 1199.000 > cache size : 8192 KB > physical id : 0 > siblings : 8 > core id : 0 > cpu cores : 4 > apicid : 1 > initial apicid : 1 > fpu : yes > fpu_exception : yes > cpuid level : 11 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall > nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 > cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi > flexpriority ept vpid > bogomips : 3724.10 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > processor : 5 > vendor_id : GenuineIntel > cpu family : 6 > model : 30 > model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz > stepping : 5 > microcode : 0x5 > cpu MHz : 1867.000 > cache size : 8192 KB > physical id : 0 > siblings : 8 > core id : 1 > cpu cores : 4 > apicid : 3 > initial apicid : 3 > fpu : yes > fpu_exception : yes > cpuid level : 11 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall > nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 > cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi > flexpriority ept vpid > bogomips : 3724.10 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > processor : 6 > vendor_id : GenuineIntel > cpu family : 6 > model : 30 > model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz > stepping : 5 > microcode : 0x5 > cpu MHz : 1867.000 > cache size : 8192 KB > physical id : 0 > siblings : 8 > core id : 2 > cpu cores : 4 > apicid : 5 > initial apicid : 5 > fpu : yes > fpu_exception : yes > cpuid level : 11 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall > nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 > cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi > flexpriority ept vpid > bogomips : 3724.10 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > processor : 7 > vendor_id : GenuineIntel > cpu family : 6 > model : 30 > model name : Intel(R) Core(TM) i7 CPU Q 840 @ 1.87GHz > stepping : 5 > microcode : 0x5 > cpu MHz : 1199.000 > cache size : 8192 KB > physical id : 0 > siblings : 8 > core id : 3 > cpu cores : 4 > apicid : 7 > initial apicid : 7 > fpu : yes > fpu_exception : yes > cpuid level : 11 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall > nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology > nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 > cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi > flexpriority ept vpid > bogomips : 3724.10 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > > > Memory: 4k page, physical 8111160k(2707952k free), swap > 10223612k(10223612k free) > > vm_info: Java HotSpot(TM) 64-Bit Server VM (20.8-b03) for linux-amd64 > JRE (1.6.0_33-b04), built on Jun 21 2012 16:28:12 by "java_re" with gcc > 3.2.2 (SuSE Linux) > > time: Mon Jul 16 14:57:38 2012 > elapsed time: 0 seconds > > _______________________________________________ > 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/20120717/92524d1d/attachment-0001.html From john.r.rose at oracle.com Mon Jul 16 20:40:18 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 17 Jul 2012 03:40:18 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: fix C2 typing anomalies around weakly-typed call sites Message-ID: <20120717034019.30471470B6@hg.openjdk.java.net> Changeset: 4765d908e696 Author: jrose Date: 2012-07-16 20:40 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/4765d908e696 meth: fix C2 typing anomalies around weakly-typed call sites ! meth-lazy-7023639.review.patch From lukas.stadler at jku.at Tue Jul 17 03:00:35 2012 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Tue, 17 Jul 2012 10:00:35 +0000 Subject: hg: mlvm/mlvm/hotspot: coro: fix coro.patch problem with vmSymbols.hpp Message-ID: <20120717100036.81EE4470CD@hg.openjdk.java.net> Changeset: c489641155e3 Author: Lukas Stadler Date: 2012-07-17 11:59 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c489641155e3 coro: fix coro.patch problem with vmSymbols.hpp ! coro.patch From lukas.stadler at jku.at Tue Jul 17 03:01:44 2012 From: lukas.stadler at jku.at (Lukas Stadler) Date: Tue, 17 Jul 2012 12:01:44 +0200 Subject: failure compiling coroutine.cpp when coro guard enabled In-Reply-To: References: Message-ID: <50053808.4080609@jku.at> I just pushed a fix for this problem... - Lukas Am 2012-07-16 07:40, schrieb John Rose: > On Jul 15, 2012, at 3:56 PM, Stephen Bannasch wrote: > >> I'm getting this error compiling coroutine.cpp when I add "coro" to >> my guards >> >> coroutine.cpp:111: error: 'startInternal_method_name' is not a >> member of 'vmSymbols' > > The problem is that the coro.patch file did not apply cleanly. A > recent rebasing to hotspot-comp has probably broken the coro script. > A relevant interfering change is this, in hotspot-comp: >> changeset: 3281:0105f367a14c >> user: rbackman >> date: Tue Mar 06 12:36:59 2012 +0100 >> summary: 7160570: Intrinsification support for tracing framework > > > The script you use to apply the patches will have reported an error, > something like this: >> 1 out of 5 hunks FAILED -- saving rejects to file >> src/share/vm/classfile/vmSymbols.hpp.rej > > If the patches fail to apply, there is little or no hope that the > build process will work. > > --- John > > > _______________________________________________ > 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/20120717/20418d9f/attachment.html From john.r.rose at oracle.com Tue Jul 17 05:23:30 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 17 Jul 2012 12:23:30 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: remove a bunch more dead code (CMH, MTF) Message-ID: <20120717122330.E4EE3470D0@hg.openjdk.java.net> Changeset: ad665697620c Author: jrose Date: 2012-07-17 05:23 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ad665697620c meth: remove a bunch more dead code (CMH, MTF) ! meth-lazy-7023639.review.patch From john.r.rose at oracle.com Tue Jul 17 05:25:55 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 17 Jul 2012 12:25:55 +0000 Subject: hg: mlvm/mlvm/jdk: meth: make BMHs be more strongly typed; various cleanups Message-ID: <20120717122555.DD17E470D1@hg.openjdk.java.net> Changeset: f07d59dc449e Author: jrose Date: 2012-07-17 05:25 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f07d59dc449e meth: make BMHs be more strongly typed; various cleanups ! meth-lazy-7023639.bmh.patch From forax at univ-mlv.fr Tue Jul 17 08:59:03 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 17 Jul 2012 17:59:03 +0200 Subject: Crash using sun.misc.Unsafe.static In-Reply-To: References: <50041304.2070703@univ-mlv.fr> Message-ID: <50058BC7.2020107@univ-mlv.fr> On 07/17/2012 01:06 AM, Krystal Mok wrote: > Hi Remi, > > Looks like it's a trap if you're running this on JDK6's HotSpot VM. If > you're running a debug build of the same VM, you should hit an > assertion before hitting the ShouldNotReachHere() part. > > opto/type.cpp:2477 > assert(o->is_java_object(), "must be java language object"); > > Even though the source code of JDK6u33 is not open sourced, you could > try a similar version of HotSpot VM from OpenJDK, namely the > hsx/hsx20/baseline branch, or jdk6/jdk6/hotspot. Make a fastdebug > build and you should see the assertion. > > And you're right that this has to do with the PermGen removal project. > The difference comes from [1], which is a part of CR 7017732. > To be specific, before the 7017732, static fields are stored in the > instanceKlass of a Java class; an instanceKlass (or its enclosing > klassOopDesc to be exact) is not an Java object. > After 7017732, static fields are moved to the tail of java.lang.Class > instances, which are Java objects. > > So to answer your question, you just shouldn't expect the the code to > work in JDK6/HotSpot. Hi Krys, Too bad because I wanted to use a similar code in the jsr292 backport (a Java agent that enable dynamic language runtime written with invokedynamic to run on a jdk6 stock VM) This remember me another question, the java agent use java.lang.instrument.Instrumentation.retransform to change code at runtime and it seems that using retransform disable OSR on the retransformed class. Is there a reason for that ? > > [1]: > http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/diff/c7f3d0b4570f/src/share/vm/prims/unsafe.cpp R?mi From john.r.rose at oracle.com Tue Jul 17 15:55:50 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 17 Jul 2012 15:55:50 -0700 Subject: Crash using sun.misc.Unsafe.static In-Reply-To: References: <50041304.2070703@univ-mlv.fr> Message-ID: <3FE02DB2-3194-4DEF-BE38-64622F2A7EB7@oracle.com> On Jul 16, 2012, at 4:06 PM, Krystal Mok wrote: > And you're right that this has to do with the PermGen removal project. The difference comes from [1], which is a part of CR 7017732. > To be specific, before the 7017732, static fields are stored in the instanceKlass of a Java class; an instanceKlass (or its enclosing klassOopDesc to be exact) is not an Java object. > After 7017732, static fields are moved to the tail of java.lang.Class instances, which are Java objects. > > So to answer your question, you just shouldn't expect the the code to work in JDK6/HotSpot. The API for unsafe access to statics is designed to allow implementations to do one of two things: 1. store a static variable at a fixed offset within a managed object (addressable via Java references) 2. store a static variable at an arbitrary but fixed 64-bit VA (in which case the object base is just null) The JDK 6 system is in a middle state, where the instanceKlass is a managed object and can move is not compatible with Java references. I think there was a time when non-Java oops could be manipulated via Java reference variables, but the practice has always been rather? unsafe. This could be fixed in JDK 6, but it's probably not worth it. I recommend spinning bytecoded accessors for statics on JDK 6. On JDK 7 and later, the Class is the base (as Kris pointed out). This is probably how it's going to stay. Thanks for the report. ? John P.S. For multi-tenancy VMs, the addressing arithmetic for statics would need to take into account the task ID. But the above design (baseOrNull + longOffset) still works, since the unsafe API doesn't say how the two components get combined. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120717/a3dc590d/attachment.html From christian.thalinger at oracle.com Tue Jul 17 16:02:17 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 17 Jul 2012 23:02:17 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: added reinvokerTarget method to BMH species Message-ID: <20120717230217.B43DA470E3@hg.openjdk.java.net> Changeset: 72d2a3526502 Author: twisti Date: 2012-07-17 16:02 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/72d2a3526502 meth-lazy: added reinvokerTarget method to BMH species ! meth-lazy-7023639.bmh.patch From christian.thalinger at oracle.com Tue Jul 17 16:04:41 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 17 Jul 2012 16:04:41 -0700 Subject: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <4FFF7983.3050905@oracle.com> References: <4FFF7983.3050905@oracle.com> Message-ID: On Jul 12, 2012, at 6:27 PM, Vladimir Kozlov wrote: > John, > > sharedRuntime_sparc.cpp: > Why casting to (int)? Also use pointer_delta(code_end, code_start,1): > + __ set((int)(intptr_t)(code_end - code_start), temp2_reg); Done. > > You bound L_fail label twice, it should be local in range_check(). Use brx() instead of br() since you compare pointers. And use cmp_and_brx_short() if delayed instruction is nop(). Done. > > Use fatal() instead of guarantee: > guarantee(false, err_msg("special_dispatch=%d", special_dispatch)); Done. > > interpreter_sparc.cpp: > In generate_method_entry() use fatal() instead of ShouldNotReachHere(): > fatal(err_msg("unexpected method kind: %d", kind)); Good idea. Done. > > > methodHandles_sparc.cpp: > In MethodHandles::verify_klass() calls restore() should be after BINDs. Argh. I haven't seen you've found this bug. It took me a while to debug this :-) > > In MethodHandles::jump_from_method_handle() use cmp_and_br_short(temp, 0, ) Done. > > Instead of 100 use strlen(name)+50: > + char* qname = NEW_C_HEAP_ARRAY(char, 100); > + jio_snprintf(qname, 100, Done. > > sharedRuntime_x86_32.cpp: > sharedRuntime_x86_64.cpp: > The same problem with L_fail label as in sharedRuntime_sparc.cpp. Done. > > templateInterpreter_x86_32.cpp: > templateInterpreter_x86_64.cpp: > Again use use fatal() instead of ShouldNotReachHere() in generate_method_entry() Done. > > I see in several files next code pattern. Should we call throw_IncompatibleClassChangeError() as we do in other places?: > > + if (!EnableInvokeDynamic) { > + // rewriter does not generate this bytecode > + __ should_not_reach_here(); > + return; > + } Hmm. This really should not happen and EnableInvokeDynamic is on by default anyway. I doubt someone turns it off. > > c1_FrameMap.cpp: > Why is ShouldNotReachHere() for mh_invoke in FrameMap::java_calling_convention()? That was old, unused code. Removed. > > c1_GraphBuilder.cpp: > add parenthesis: > const bool is_invokedynamic = code == Bytecodes::_invokedynamic; Done. > > nmethod.cpp: > Don't put printing nmethod's addresses under Verbose flag. Leftover. Removed. > > linkResolver.cpp: > Can you replace infinite for(;;) in resolve_invokedynamic() with finite loop since the body is executed once or twice. Hmm. What limit do you have in mind? > > templateInterpreter.cpp: > why you need additional {} around the loop? We don't. I think it was used for better visibility of the MH code. Removed. > > constantPoolOop.cpp: > Why not use guarantee() for bad operants? Not sure. John? > Why you need separate scopes in resolve_bootstrap_specifier_at_impl()? To keep oops from being visible. Might result in bad crashes. > > symbol.cpp: > The loop in index_of_at() should be for(; scan <= limit; scan++) and after loop return -1. Done. > > bytecodeInfo.cpp: > Don't add spaces into conditions, looks strange. It's more readable: if ( callee->is_native()) return "native method"; if ( callee->is_abstract()) return "abstract method"; if (!callee->can_be_compiled()) return "not compilable (disabled)"; if (!callee->has_balanced_monitors()) return "not compilable (unbalanced monitors)"; if ( callee->get_flow_analysis()->failing()) return "not compilable (flow analysis failed)"; vs. if (callee->is_native()) return "native method"; if (callee->is_abstract()) return "abstract method"; if (!callee->can_be_compiled()) return "not compilable (disabled)"; if (!callee->has_balanced_monitors()) return "not compilable (unbalanced monitors)"; if (callee->get_flow_analysis()->failing()) return "not compilable (flow analysis failed)"; You REALLY want me to remove it? ;-) > Remove commented code for inline ForceInline methods. Agreed. We need to revisit that anyway. > > callGenerator.cpp: > Please, decide which code to use: +#if 1. And I don't think new code is correct. PredictedDynamicCallGenerator is dead. Removed. > > graphKit.cpp: > Remove commented debug print. Done. > insert_argument() and remove_argument() are not used. Correct. Removed. I will refresh the review patch in mlvm. Thank you! -- Chris > > > Vladimir > > John Rose wrote: >> As some of you have noticed, Chris Thalinger, Michael Haupt, and I have been working on the mlvm patches [1] for JEP-160 [2] for several months. These changes make method handles more optimizable. They refactor lots of "magic" out of the JVM and into more manageable Java code. >> To get an idea of how much "magic" is being removed, consider that the change removes 12,000 lines of non-comment code from the JVM, including much assembly code. It inserts 4900 lines of non-comment code. >> These changes are now stable enough to integrate. They pass jtreg tests in a number of execution modes and platforms. They also correctly run various JRuby and Nashorn test programs. Although there are no performance gains to boast about at present, these changes clear the ground for long-term optimization work. >> Here is the webrev [3], for review and integration into JDK 8 via hotspot-comp/hotspot/. >> Because of the large size of this change set, we request that reviewers would clearly designate which files they are reviewing. That way we may be able to divide up the work a little more effectively. >> Also, because of the scope of the change, we may respond to some comments by promising to address an issue in a future change set. If necessary, we will file tracking bugs to make sure nothing gets dropped. We have been working on this for months, and expect to make many further changes. >> The immediate need to get the changes in is twofold: First, some bugs (involving symbolic references off the boot class path) require the new Lambda Form intermediate representation, which is "off-BCP-clean". Second, we need to commit our pervasive changes to the JVM sooner rather than later, so they can be properly integrated with other pervasive changes, such as metadata changes. >> An associated webrev for hotspot-comp/jdk/ will be posted soon; it is already present on mlvm-dev for the curious to examine. (This change set also deletes a lot of old code.) >> Thanks in advance, >> ? John >> [1] http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy-7023639.patch >> [2] http://openjdk.java.net/jeps/160 >> [3] http://cr.openjdk.java.net/~jrose/7023639/webrev.00/ From vladimir.kozlov at oracle.com Tue Jul 17 16:32:12 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Jul 2012 16:32:12 -0700 Subject: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: References: <4FFF7983.3050905@oracle.com> Message-ID: <5005F5FC.8030204@oracle.com> >> linkResolver.cpp: >> Can you replace infinite for(;;) in resolve_invokedynamic() with finite loop since the body is executed once or twice. > > Hmm. What limit do you have in mind? It is not loop by logic. The code is trying to avoid double the check for CallSite has been bound already. I think it could be re-arranged as next: + Handle bootstrap_specifier; + // Check if CallSite has been bound already: + ConstantPoolCacheEntry* cpce = pool->cache()->secondary_entry_at(index); + if (cpce->is_f1_null()) { + int pool_index = pool->cache()->main_entry_at(index)->constant_pool_index(); + oop bsm_info = pool->resolve_bootstrap_specifier_at(pool_index, CHECK); + assert(bsm_info != NULL, ""); + // FIXME: Cache this once per BootstrapMethods entry, not once per CONSTANT_InvokeDynamic. + bootstrap_specifier = Handle(THREAD, bsm_info); + } + if (!cpce->is_f1_null()) { + methodHandle method(THREAD, cpce->f2_as_vfinal_method()); + Handle appendix(THREAD, cpce->has_appendix() ? cpce->f1_appendix() : (oop)NULL); + result.set_handle(method, appendix, CHECK); + return; + } >> bytecodeInfo.cpp: >> Don't add spaces into conditions, looks strange. > You REALLY want me to remove it? ;-) No, you can leave it as it is. Vladimir Christian Thalinger wrote: > On Jul 12, 2012, at 6:27 PM, Vladimir Kozlov wrote: > >> John, >> >> sharedRuntime_sparc.cpp: >> Why casting to (int)? Also use pointer_delta(code_end, code_start,1): >> + __ set((int)(intptr_t)(code_end - code_start), temp2_reg); > > Done. > >> You bound L_fail label twice, it should be local in range_check(). Use brx() instead of br() since you compare pointers. And use cmp_and_brx_short() if delayed instruction is nop(). > > Done. > >> Use fatal() instead of guarantee: >> guarantee(false, err_msg("special_dispatch=%d", special_dispatch)); > > Done. > >> interpreter_sparc.cpp: >> In generate_method_entry() use fatal() instead of ShouldNotReachHere(): >> fatal(err_msg("unexpected method kind: %d", kind)); > > Good idea. Done. > >> >> methodHandles_sparc.cpp: >> In MethodHandles::verify_klass() calls restore() should be after BINDs. > > Argh. I haven't seen you've found this bug. It took me a while to debug this :-) > >> In MethodHandles::jump_from_method_handle() use cmp_and_br_short(temp, 0, ) > > Done. > >> Instead of 100 use strlen(name)+50: >> + char* qname = NEW_C_HEAP_ARRAY(char, 100); >> + jio_snprintf(qname, 100, > > Done. > >> sharedRuntime_x86_32.cpp: >> sharedRuntime_x86_64.cpp: >> The same problem with L_fail label as in sharedRuntime_sparc.cpp. > > Done. > >> templateInterpreter_x86_32.cpp: >> templateInterpreter_x86_64.cpp: >> Again use use fatal() instead of ShouldNotReachHere() in generate_method_entry() > > Done. > >> I see in several files next code pattern. Should we call throw_IncompatibleClassChangeError() as we do in other places?: >> >> + if (!EnableInvokeDynamic) { >> + // rewriter does not generate this bytecode >> + __ should_not_reach_here(); >> + return; >> + } > > Hmm. This really should not happen and EnableInvokeDynamic is on by default anyway. I doubt someone turns it off. > >> c1_FrameMap.cpp: >> Why is ShouldNotReachHere() for mh_invoke in FrameMap::java_calling_convention()? > > That was old, unused code. Removed. > >> c1_GraphBuilder.cpp: >> add parenthesis: >> const bool is_invokedynamic = code == Bytecodes::_invokedynamic; > > Done. > >> nmethod.cpp: >> Don't put printing nmethod's addresses under Verbose flag. > > Leftover. Removed. > >> linkResolver.cpp: >> Can you replace infinite for(;;) in resolve_invokedynamic() with finite loop since the body is executed once or twice. > > Hmm. What limit do you have in mind? > >> templateInterpreter.cpp: >> why you need additional {} around the loop? > > We don't. I think it was used for better visibility of the MH code. Removed. > >> constantPoolOop.cpp: >> Why not use guarantee() for bad operants? > > Not sure. John? > >> Why you need separate scopes in resolve_bootstrap_specifier_at_impl()? > > To keep oops from being visible. Might result in bad crashes. > >> symbol.cpp: >> The loop in index_of_at() should be for(; scan <= limit; scan++) and after loop return -1. > > Done. > >> bytecodeInfo.cpp: >> Don't add spaces into conditions, looks strange. > > It's more readable: > > if ( callee->is_native()) return "native method"; > if ( callee->is_abstract()) return "abstract method"; > if (!callee->can_be_compiled()) return "not compilable (disabled)"; > if (!callee->has_balanced_monitors()) return "not compilable (unbalanced monitors)"; > if ( callee->get_flow_analysis()->failing()) return "not compilable (flow analysis failed)"; > > vs. > > if (callee->is_native()) return "native method"; > if (callee->is_abstract()) return "abstract method"; > if (!callee->can_be_compiled()) return "not compilable (disabled)"; > if (!callee->has_balanced_monitors()) return "not compilable (unbalanced monitors)"; > if (callee->get_flow_analysis()->failing()) return "not compilable (flow analysis failed)"; > > You REALLY want me to remove it? ;-) > >> Remove commented code for inline ForceInline methods. > > Agreed. We need to revisit that anyway. > >> callGenerator.cpp: >> Please, decide which code to use: +#if 1. And I don't think new code is correct. > > PredictedDynamicCallGenerator is dead. Removed. > >> graphKit.cpp: >> Remove commented debug print. > > Done. > >> insert_argument() and remove_argument() are not used. > > Correct. Removed. > > I will refresh the review patch in mlvm. Thank you! > > -- Chris > >> >> Vladimir >> >> John Rose wrote: >>> As some of you have noticed, Chris Thalinger, Michael Haupt, and I have been working on the mlvm patches [1] for JEP-160 [2] for several months. These changes make method handles more optimizable. They refactor lots of "magic" out of the JVM and into more manageable Java code. >>> To get an idea of how much "magic" is being removed, consider that the change removes 12,000 lines of non-comment code from the JVM, including much assembly code. It inserts 4900 lines of non-comment code. >>> These changes are now stable enough to integrate. They pass jtreg tests in a number of execution modes and platforms. They also correctly run various JRuby and Nashorn test programs. Although there are no performance gains to boast about at present, these changes clear the ground for long-term optimization work. >>> Here is the webrev [3], for review and integration into JDK 8 via hotspot-comp/hotspot/. >>> Because of the large size of this change set, we request that reviewers would clearly designate which files they are reviewing. That way we may be able to divide up the work a little more effectively. >>> Also, because of the scope of the change, we may respond to some comments by promising to address an issue in a future change set. If necessary, we will file tracking bugs to make sure nothing gets dropped. We have been working on this for months, and expect to make many further changes. >>> The immediate need to get the changes in is twofold: First, some bugs (involving symbolic references off the boot class path) require the new Lambda Form intermediate representation, which is "off-BCP-clean". Second, we need to commit our pervasive changes to the JVM sooner rather than later, so they can be properly integrated with other pervasive changes, such as metadata changes. >>> An associated webrev for hotspot-comp/jdk/ will be posted soon; it is already present on mlvm-dev for the curious to examine. (This change set also deletes a lot of old code.) >>> Thanks in advance, >>> ? John >>> [1] http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy-7023639.patch >>> [2] http://openjdk.java.net/jeps/160 >>> [3] http://cr.openjdk.java.net/~jrose/7023639/webrev.00/ > From forax at univ-mlv.fr Tue Jul 17 16:39:46 2012 From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=) Date: Wed, 18 Jul 2012 01:39:46 +0200 Subject: Crash using sun.misc.Unsafe.static In-Reply-To: <3FE02DB2-3194-4DEF-BE38-64622F2A7EB7@oracle.com> References: <50041304.2070703@univ-mlv.fr> <3FE02DB2-3194-4DEF-BE38-64622F2A7EB7@oracle.com> Message-ID: <5005F7C2.9010900@univ-mlv.fr> On 07/18/2012 12:55 AM, John Rose wrote: > On Jul 16, 2012, at 4:06 PM, Krystal Mok wrote: > >> And you're right that this has to do with the PermGen removal >> project. The difference comes from [1], which is a part of CR 7017732. >> To be specific, before the 7017732, static fields are stored in the >> instanceKlass of a Java class; an instanceKlass (or its enclosing >> klassOopDesc to be exact) is not an Java object. >> After 7017732, static fields are moved to the tail of java.lang.Class >> instances, which are Java objects. >> >> So to answer your question, you just shouldn't expect the the code to >> work in JDK6/HotSpot. > > The API for unsafe access to statics is designed to allow > implementations to do one of two things: > > 1. store a static variable at a fixed offset within a managed object > (addressable via Java references) > 2. store a static variable at an arbitrary but fixed 64-bit VA (in > which case the object base is just null) > > The JDK 6 system is in a middle state, where the instanceKlass is a > managed object and can move is not compatible with Java references. > I think there was a time when non-Java oops could be manipulated via > Java reference variables, but the practice has always been rather? unsafe. > > This could be fixed in JDK 6, but it's probably not worth it. I > recommend spinning bytecoded accessors for statics on JDK 6. On JDK 7 > and later, the Class is the base (as Kris pointed out). This is > probably how it's going to stay. I spin bytecode by default if the field is visible from the callsite and wanted to use unsafe with a constant base object if the field is not visible. So to workaround that bug, I store the base object in a non-constant field exactly like reflection does, so it works on jdk6. Exactly, I should try to detect if the VM is hotspot or not because neither JRockit nor J9 have the same issue. > > Thanks for the report. > > ? John > > P.S. For multi-tenancy VMs, the addressing arithmetic for statics > would need to take into account the task ID. But the above design > (baseOrNull + longOffset) still works, since the unsafe API doesn't > say how the two components get combined. R?mi From christian.thalinger at oracle.com Tue Jul 17 17:01:17 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 18 Jul 2012 00:01:17 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: update for review comments Message-ID: <20120718000117.4E6C7470E8@hg.openjdk.java.net> Changeset: 9717ee54c9f5 Author: twisti Date: 2012-07-17 17:00 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9717ee54c9f5 meth-lazy: update for review comments ! meth-lazy-7023639.review.patch From john.r.rose at oracle.com Tue Jul 17 17:03:43 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 18 Jul 2012 00:03:43 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: add stronger typing to field accessor base pointers; constructor bug fix Message-ID: <20120718000343.BA72E470E9@hg.openjdk.java.net> Changeset: c73fecb5e075 Author: jrose Date: 2012-07-17 17:03 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/c73fecb5e075 meth-lazy: add stronger typing to field accessor base pointers; constructor bug fix ! meth-lazy-7023639.bmh.patch From aleksey.shipilev at oracle.com Wed Jul 18 01:43:31 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 18 Jul 2012 12:43:31 +0400 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code Message-ID: <50067733.7080808@oracle.com> (sorry for not replying to original message, just subscribed) This feels outright wrong: + static Map CACHE = new IdentityHashMap<>(); + + static Data get(String types) { + final String key = types.intern(); + Data d = CACHE.get(key); + if (d == null) { + d = make(types); + Data e = CACHE.get(key); + if (e != null) { + d = e; + } else { + CACHE.put(key, d); + } + } + return d; + } I couple of questions pops out in my mind: 1. Is this code supposed to be thread-safe? It is then wrong to use unguarded IdentityHashMap without external synchronization. 2. Do we really need a second .get() check, if code is not thread-safe anyway? This code allows two threads to call put() on the same key anyway. 3. Do the $types *need* to be interned? Or is this the premature optimization (gone wrong, btw)? I would rather like to see CHM.putIfAbsent()-based cache on plain non-interned strings there. Even if interned strings are required, we could intern them on successful map update, not every time we look up the key. -Aleksey. From mroos at roos.com Wed Jul 18 16:24:01 2012 From: mroos at roos.com (Mark Roos) Date: Wed, 18 Jul 2012 16:24:01 -0700 Subject: Testing RTALK on JDK8 MLVM Message-ID: FWIW Everything RTALK works on Stephen's 7/11/2012 build. Thank you Stephen. While generally faster than 7u2 I do have a strangeness in that when my target is a chain of methodHandles its much slower then when my target is a methodHandle-callsite-chain of handles. My second case is where I add a debugging trap at the start of each chain. Its slower by 4 to 1. 7U2 does not seem to do this. I would guess the issue is that hot spot optimizes the second but not the first. Perhaps some inline depth or related limit? Are they any runtime flags I should play with? ( tiered compile?) In summary I am happy with the progress. Currently my fully dynamic implementation of Hanoi is about 2x slower than a pure Java version. ( 20% better than 7u2). thanks to all mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120718/871301ed/attachment.html From christian.thalinger at oracle.com Wed Jul 18 17:11:14 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 18 Jul 2012 17:11:14 -0700 Subject: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <5005F5FC.8030204@oracle.com> References: <4FFF7983.3050905@oracle.com> <5005F5FC.8030204@oracle.com> Message-ID: On Jul 17, 2012, at 4:32 PM, Vladimir Kozlov wrote: > >> linkResolver.cpp: > >> Can you replace infinite for(;;) in resolve_invokedynamic() with finite loop since the body is executed once or twice. > > > > Hmm. What limit do you have in mind? > > It is not loop by logic. The code is trying to avoid double the check for CallSite has been bound already. I think it could be re-arranged as next: > > + Handle bootstrap_specifier; > + // Check if CallSite has been bound already: > + ConstantPoolCacheEntry* cpce = pool->cache()->secondary_entry_at(index); > + if (cpce->is_f1_null()) { > + int pool_index = pool->cache()->main_entry_at(index)->constant_pool_index(); > + oop bsm_info = pool->resolve_bootstrap_specifier_at(pool_index, CHECK); > + assert(bsm_info != NULL, ""); > + // FIXME: Cache this once per BootstrapMethods entry, not once per CONSTANT_InvokeDynamic. > + bootstrap_specifier = Handle(THREAD, bsm_info); > + } > + if (!cpce->is_f1_null()) { > + methodHandle method(THREAD, cpce->f2_as_vfinal_method()); > + Handle appendix(THREAD, cpce->has_appendix() ? cpce->f1_appendix() : (oop)NULL); > + result.set_handle(method, appendix, CHECK); > + return; > + } Much better. Done. -- Chris > > >> bytecodeInfo.cpp: > >> Don't add spaces into conditions, looks strange. > > You REALLY want me to remove it? ;-) > > No, you can leave it as it is. > > Vladimir > > Christian Thalinger wrote: >> On Jul 12, 2012, at 6:27 PM, Vladimir Kozlov wrote: >>> John, >>> >>> sharedRuntime_sparc.cpp: >>> Why casting to (int)? Also use pointer_delta(code_end, code_start,1): >>> + __ set((int)(intptr_t)(code_end - code_start), temp2_reg); >> Done. >>> You bound L_fail label twice, it should be local in range_check(). Use brx() instead of br() since you compare pointers. And use cmp_and_brx_short() if delayed instruction is nop(). >> Done. >>> Use fatal() instead of guarantee: >>> guarantee(false, err_msg("special_dispatch=%d", special_dispatch)); >> Done. >>> interpreter_sparc.cpp: >>> In generate_method_entry() use fatal() instead of ShouldNotReachHere(): >>> fatal(err_msg("unexpected method kind: %d", kind)); >> Good idea. Done. >>> >>> methodHandles_sparc.cpp: >>> In MethodHandles::verify_klass() calls restore() should be after BINDs. >> Argh. I haven't seen you've found this bug. It took me a while to debug this :-) >>> In MethodHandles::jump_from_method_handle() use cmp_and_br_short(temp, 0, ) >> Done. >>> Instead of 100 use strlen(name)+50: >>> + char* qname = NEW_C_HEAP_ARRAY(char, 100); >>> + jio_snprintf(qname, 100, >> Done. >>> sharedRuntime_x86_32.cpp: >>> sharedRuntime_x86_64.cpp: >>> The same problem with L_fail label as in sharedRuntime_sparc.cpp. >> Done. >>> templateInterpreter_x86_32.cpp: >>> templateInterpreter_x86_64.cpp: >>> Again use use fatal() instead of ShouldNotReachHere() in generate_method_entry() >> Done. >>> I see in several files next code pattern. Should we call throw_IncompatibleClassChangeError() as we do in other places?: >>> >>> + if (!EnableInvokeDynamic) { >>> + // rewriter does not generate this bytecode >>> + __ should_not_reach_here(); >>> + return; >>> + } >> Hmm. This really should not happen and EnableInvokeDynamic is on by default anyway. I doubt someone turns it off. >>> c1_FrameMap.cpp: >>> Why is ShouldNotReachHere() for mh_invoke in FrameMap::java_calling_convention()? >> That was old, unused code. Removed. >>> c1_GraphBuilder.cpp: >>> add parenthesis: >>> const bool is_invokedynamic = code == Bytecodes::_invokedynamic; >> Done. >>> nmethod.cpp: >>> Don't put printing nmethod's addresses under Verbose flag. >> Leftover. Removed. >>> linkResolver.cpp: >>> Can you replace infinite for(;;) in resolve_invokedynamic() with finite loop since the body is executed once or twice. >> Hmm. What limit do you have in mind? >>> templateInterpreter.cpp: >>> why you need additional {} around the loop? >> We don't. I think it was used for better visibility of the MH code. Removed. >>> constantPoolOop.cpp: >>> Why not use guarantee() for bad operants? >> Not sure. John? >>> Why you need separate scopes in resolve_bootstrap_specifier_at_impl()? >> To keep oops from being visible. Might result in bad crashes. >>> symbol.cpp: >>> The loop in index_of_at() should be for(; scan <= limit; scan++) and after loop return -1. >> Done. >>> bytecodeInfo.cpp: >>> Don't add spaces into conditions, looks strange. >> It's more readable: >> if ( callee->is_native()) return "native method"; >> if ( callee->is_abstract()) return "abstract method"; >> if (!callee->can_be_compiled()) return "not compilable (disabled)"; >> if (!callee->has_balanced_monitors()) return "not compilable (unbalanced monitors)"; >> if ( callee->get_flow_analysis()->failing()) return "not compilable (flow analysis failed)"; >> vs. >> if (callee->is_native()) return "native method"; >> if (callee->is_abstract()) return "abstract method"; >> if (!callee->can_be_compiled()) return "not compilable (disabled)"; >> if (!callee->has_balanced_monitors()) return "not compilable (unbalanced monitors)"; >> if (callee->get_flow_analysis()->failing()) return "not compilable (flow analysis failed)"; >> You REALLY want me to remove it? ;-) >>> Remove commented code for inline ForceInline methods. >> Agreed. We need to revisit that anyway. >>> callGenerator.cpp: >>> Please, decide which code to use: +#if 1. And I don't think new code is correct. >> PredictedDynamicCallGenerator is dead. Removed. >>> graphKit.cpp: >>> Remove commented debug print. >> Done. >>> insert_argument() and remove_argument() are not used. >> Correct. Removed. >> I will refresh the review patch in mlvm. Thank you! >> -- Chris >>> >>> Vladimir >>> >>> John Rose wrote: >>>> As some of you have noticed, Chris Thalinger, Michael Haupt, and I have been working on the mlvm patches [1] for JEP-160 [2] for several months. These changes make method handles more optimizable. They refactor lots of "magic" out of the JVM and into more manageable Java code. >>>> To get an idea of how much "magic" is being removed, consider that the change removes 12,000 lines of non-comment code from the JVM, including much assembly code. It inserts 4900 lines of non-comment code. >>>> These changes are now stable enough to integrate. They pass jtreg tests in a number of execution modes and platforms. They also correctly run various JRuby and Nashorn test programs. Although there are no performance gains to boast about at present, these changes clear the ground for long-term optimization work. >>>> Here is the webrev [3], for review and integration into JDK 8 via hotspot-comp/hotspot/. >>>> Because of the large size of this change set, we request that reviewers would clearly designate which files they are reviewing. That way we may be able to divide up the work a little more effectively. >>>> Also, because of the scope of the change, we may respond to some comments by promising to address an issue in a future change set. If necessary, we will file tracking bugs to make sure nothing gets dropped. We have been working on this for months, and expect to make many further changes. >>>> The immediate need to get the changes in is twofold: First, some bugs (involving symbolic references off the boot class path) require the new Lambda Form intermediate representation, which is "off-BCP-clean". Second, we need to commit our pervasive changes to the JVM sooner rather than later, so they can be properly integrated with other pervasive changes, such as metadata changes. >>>> An associated webrev for hotspot-comp/jdk/ will be posted soon; it is already present on mlvm-dev for the curious to examine. (This change set also deletes a lot of old code.) >>>> Thanks in advance, >>>> ? John >>>> [1] http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy-7023639.patch >>>> [2] http://openjdk.java.net/jeps/160 >>>> [3] http://cr.openjdk.java.net/~jrose/7023639/webrev.00/ From christian.thalinger at oracle.com Wed Jul 18 17:12:01 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 19 Jul 2012 00:12:01 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: update for review comments Message-ID: <20120719001201.E92BF47130@hg.openjdk.java.net> Changeset: 65906046e5fd Author: twisti Date: 2012-07-18 17:11 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/65906046e5fd meth-lazy: update for review comments ! meth-lazy-7023639.review.patch From christian.thalinger at oracle.com Wed Jul 18 18:57:48 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 19 Jul 2012 01:57:48 +0000 Subject: hg: mlvm/mlvm/hotspot: rebase to current hsx/hotspot-comp Message-ID: <20120719015749.5D73D47134@hg.openjdk.java.net> Changeset: 88f29874d717 Author: twisti Date: 2012-07-18 18:57 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/88f29874d717 rebase to current hsx/hotspot-comp ! meth-lazy-7023639.patch ! meth-lazy-7023639.review.patch ! series From john.r.rose at oracle.com Wed Jul 18 19:10:44 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 18 Jul 2012 19:10:44 -0700 Subject: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: References: <4FFF7983.3050905@oracle.com> Message-ID: <9B5E715C-FD6B-48C3-9A1C-B7FB1581E663@oracle.com> On Jul 17, 2012, at 4:04 PM, Christian Thalinger wrote: >> >> I see in several files next code pattern. Should we call throw_IncompatibleClassChangeError() as we do in other places?: >> >> + if (!EnableInvokeDynamic) { >> + // rewriter does not generate this bytecode >> + __ should_not_reach_here(); >> + return; >> + } > > Hmm. This really should not happen and EnableInvokeDynamic is on by default anyway. I doubt someone turns it off. It's now a diagnostic switch. It can be used to verify that an app. is not using 292, which is occasionally helpful. >> constantPoolOop.cpp: >> Why not use guarantee() for bad operants? > > Not sure. John? The code in that file uses assert; I think I'm following the existing practice there. The CP code operates after initial verification passes, so assert is suitable, I think. >> Why you need separate scopes in resolve_bootstrap_specifier_at_impl()? > > To keep oops from being visible. Might result in bad crashes. Yes. An alternative is to have the x_oop variables visible at top level, but to put in DEBUG_ONLY(x_oop = NULL). Having the temporary scoped seems cleaner to me, but maybe my sense of style is off here. > > I will refresh the review patch in mlvm. Thank you! Yes, thanks! ? John From john.r.rose at oracle.com Thu Jul 19 00:23:16 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 19 Jul 2012 07:23:16 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: fix EA bug (contributed by kvn) Message-ID: <20120719072316.683C847138@hg.openjdk.java.net> Changeset: 13510fe048e4 Author: jrose Date: 2012-07-19 00:23 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/13510fe048e4 meth-lazy: fix EA bug (contributed by kvn) ! meth-lazy-7023639.review.patch From john.r.rose at oracle.com Thu Jul 19 00:27:41 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 19 Jul 2012 07:27:41 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: simplify field accessor code Message-ID: <20120719072742.5DF1247139@hg.openjdk.java.net> Changeset: b6a3c70ad80a Author: jrose Date: 2012-07-19 00:27 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/b6a3c70ad80a meth-lazy: simplify field accessor code ! meth-lazy-7023639.bmh.patch From john.r.rose at oracle.com Thu Jul 19 01:14:46 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 19 Jul 2012 01:14:46 -0700 Subject: Testing RTALK on JDK8 MLVM In-Reply-To: References: Message-ID: On Jul 18, 2012, at 4:24 PM, Mark Roos wrote: > While generally faster than 7u2 I do have a strangeness in that when my > target is a chain of methodHandles its much slower then when my target > is a methodHandle-callsite-chain of handles. My second case is where I add > a debugging trap at the start of each chain. Its slower by 4 to 1. The use case of a MH/CS chain is interesting. I have made a note to build a micro benchmark and see if anything is obviously wrong. (I will also gladly accept micro benchmarks from the community!) > 7U2 does not seem to do this. > > I would guess the issue is that hot spot optimizes the second but not the > first. Perhaps some inline depth or related limit? Are they any runtime flags > I should play with? ( tiered compile?) The best peak performance comes from -server, which (IIRC) is the same as -XX:-TieredCompilation. If you run with -XX:+PrintCompilation and -XX:+TieredCompilation, you will see methods getting compiled twice at levels 3 and 4. For example: ? 144 43 3 java.lang.String::indexOf (7 bytes) @ 3 java.lang.String::indexOf (70 bytes) callee is too large ? 4972 550 4 java.lang.String::indexOf (7 bytes) @ 3 java.lang.String::indexOf (70 bytes) inline (hot) @ 66 java.lang.String::indexOfSupplementary (71 bytes) too big ? This says that at 0.144 seconds, we got a profiled-client (tier 3) compilation, and after almost 5 seconds it was recompiled by the server compiler (tier 4). The "@" lines come from -XX:+PrintInlining. > In summary I am happy with the progress. Currently my fully dynamic implementation > of Hanoi is about 2x slower than a pure Java version. ( 20% better than 7u2). Thanks, Mark. It's great working with you on the bleeding edge. We think the new format for MHs will allow us to make optimizations more easily. In other words, there is suddenly lots of low-hanging fruit. Chris Thalinger did a small change yesterday that sped up one of our benchmarks by a factor of 1.8. This is probably reflected in your numbers already. But we'll do more! ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120719/7cc8599d/attachment-0001.html From mroos at roos.com Thu Jul 19 10:15:16 2012 From: mroos at roos.com (Mark Roos) Date: Thu, 19 Jul 2012 10:15:16 -0700 Subject: Testing RTALK on JDK8 MLVM In-Reply-To: References: Message-ID: Thanks John, don't jump right in to my report. I'll look into it more and I really don't want to sidetrack you. I did run with several flag choices ( server, tiered, debug agent ) and found only about a 10% difference after I let hotspot stabilize. I am pretty sure I don't have Christian's patch so I look forward to more. My best setup is 687/450 vs standard Java. For whatever reason the repeatable slowness of yesterday is not apparent today. Is there any way from within ( or from a debug agent ) to tell hotspot to forget all optimization? I also see a few of these. 430 COMPILE SKIPPED: invalid non-klass dependency 704 COMPILE SKIPPED: out of nodes parsing method (not retryable) ( server mode ) 1623 COMPILE SKIPPED: out of nodes parsing method (retry at different tier) I am going to retrace yesterday's setup to see where the 4X slowdown came from regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120719/d616f894/attachment.html From christian.thalinger at oracle.com Thu Jul 19 11:28:42 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 19 Jul 2012 11:28:42 -0700 Subject: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <9B5E715C-FD6B-48C3-9A1C-B7FB1581E663@oracle.com> References: <4FFF7983.3050905@oracle.com> <9B5E715C-FD6B-48C3-9A1C-B7FB1581E663@oracle.com> Message-ID: JDK testing found a small bug: diff --git a/src/share/vm/oops/cpCacheOop.cpp b/src/share/vm/oops/cpCacheOop.cpp --- a/src/share/vm/oops/cpCacheOop.cpp +++ b/src/share/vm/oops/cpCacheOop.cpp @@ -486,7 +486,8 @@ // virtual and final so _f2 contains method ptr instead of vtable index if (f2_as_vfinal_method() == old_method) { // match old_method so need an update - set_f2_as_vfinal_method(new_method); + // NOTE: can't use set_f2_as_vfinal_method as it asserts on different values + _f2 = (intptr_t)new_method; if (RC_TRACE_IN_RANGE(0x00100000, 0x00400000)) { if (!(*trace_name_printed)) { // RC_TRACE_MESG macro has an embedded ResourceMark I will integrate this one. -- Chris On Jul 18, 2012, at 7:10 PM, John Rose wrote: > On Jul 17, 2012, at 4:04 PM, Christian Thalinger wrote: > >>> >>> I see in several files next code pattern. Should we call throw_IncompatibleClassChangeError() as we do in other places?: >>> >>> + if (!EnableInvokeDynamic) { >>> + // rewriter does not generate this bytecode >>> + __ should_not_reach_here(); >>> + return; >>> + } >> >> Hmm. This really should not happen and EnableInvokeDynamic is on by default anyway. I doubt someone turns it off. > > It's now a diagnostic switch. It can be used to verify that an app. is not using 292, which is occasionally helpful. > >>> constantPoolOop.cpp: >>> Why not use guarantee() for bad operants? >> >> Not sure. John? > > The code in that file uses assert; I think I'm following the existing practice there. The CP code operates after initial verification passes, so assert is suitable, I think. > >>> Why you need separate scopes in resolve_bootstrap_specifier_at_impl()? >> >> To keep oops from being visible. Might result in bad crashes. > > Yes. An alternative is to have the x_oop variables visible at top level, but to put in DEBUG_ONLY(x_oop = NULL). Having the temporary scoped seems cleaner to me, but maybe my sense of style is off here. > >> >> I will refresh the review patch in mlvm. Thank you! > > Yes, thanks! > > ? John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From john.r.rose at oracle.com Thu Jul 19 12:08:33 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 19 Jul 2012 12:08:33 -0700 Subject: Testing RTALK on JDK8 MLVM In-Reply-To: References: Message-ID: <188510E9-5325-4998-BF1A-E846FE8F41C7@oracle.com> On Jul 19, 2012, at 10:15 AM, Mark Roos wrote: > Is there any way from within ( or from a debug agent ) to tell hotspot to > forget all optimization? Not really. There is -Xint which runs only in the interpreter. And -client or -XX:TieredStopAtLevel=1 which turns off C2. > I also see a few of these. > > 430 COMPILE SKIPPED: invalid non-klass dependency > > 704 COMPILE SKIPPED: out of nodes parsing method (not retryable) ( server mode ) > > 1623 COMPILE SKIPPED: out of nodes parsing method (retry at different tier) > > I am going to retrace yesterday's setup to see where the 4X slowdown came from There are a couple of compile-skipped conditions we are thinking about fixing. The out of nodes message means our inlining policy needs adjusting. The dependency one, as long as it's rare, is just par for the course. The compiler runs asynchronously, and occasionally it uses data that has changed by the time the compilation task ends. There is a transactional mechanism that re-validates dependencies before the compiled code is committed to the code cache. There's no way to guarantee the revalidation; we just expect it to be a 99% kind of thing. We also see this failure in our testing: 4168 COMPILE SKIPPED: unlinked call site (FIXME needs patching or recompile support) (retry at different tier) That's because of missing patch logic for C1-compiling unlinked indy and MH call sites. The failure kicks the job up to C2 which has a different tactic for this corner case. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120719/f3ff14d1/attachment.html From christian.thalinger at oracle.com Thu Jul 19 13:56:59 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 19 Jul 2012 20:56:59 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: small bugfix Message-ID: <20120719205700.028874714F@hg.openjdk.java.net> Changeset: cc59efc75960 Author: twisti Date: 2012-07-19 13:56 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/cc59efc75960 meth-lazy: small bugfix ! meth-lazy-7023639.review.patch From christian.thalinger at oracle.com Thu Jul 19 15:10:04 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 19 Jul 2012 15:10:04 -0700 Subject: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: References: <4FFF7983.3050905@oracle.com> <9B5E715C-FD6B-48C3-9A1C-B7FB1581E663@oracle.com> Message-ID: We forgot to remove the Ricochet Frame code from the sA: http://cr.openjdk.java.net/~twisti/7023639/ -- Chris On Jul 19, 2012, at 11:28 AM, Christian Thalinger wrote: > JDK testing found a small bug: > > diff --git a/src/share/vm/oops/cpCacheOop.cpp b/src/share/vm/oops/cpCacheOop.cpp > --- a/src/share/vm/oops/cpCacheOop.cpp > +++ b/src/share/vm/oops/cpCacheOop.cpp > @@ -486,7 +486,8 @@ > // virtual and final so _f2 contains method ptr instead of vtable index > if (f2_as_vfinal_method() == old_method) { > // match old_method so need an update > - set_f2_as_vfinal_method(new_method); > + // NOTE: can't use set_f2_as_vfinal_method as it asserts on different values > + _f2 = (intptr_t)new_method; > if (RC_TRACE_IN_RANGE(0x00100000, 0x00400000)) { > if (!(*trace_name_printed)) { > // RC_TRACE_MESG macro has an embedded ResourceMark > > I will integrate this one. > > -- Chris > > On Jul 18, 2012, at 7:10 PM, John Rose wrote: > >> On Jul 17, 2012, at 4:04 PM, Christian Thalinger wrote: >> >>>> >>>> I see in several files next code pattern. Should we call throw_IncompatibleClassChangeError() as we do in other places?: >>>> >>>> + if (!EnableInvokeDynamic) { >>>> + // rewriter does not generate this bytecode >>>> + __ should_not_reach_here(); >>>> + return; >>>> + } >>> >>> Hmm. This really should not happen and EnableInvokeDynamic is on by default anyway. I doubt someone turns it off. >> >> It's now a diagnostic switch. It can be used to verify that an app. is not using 292, which is occasionally helpful. >> >>>> constantPoolOop.cpp: >>>> Why not use guarantee() for bad operants? >>> >>> Not sure. John? >> >> The code in that file uses assert; I think I'm following the existing practice there. The CP code operates after initial verification passes, so assert is suitable, I think. >> >>>> Why you need separate scopes in resolve_bootstrap_specifier_at_impl()? >>> >>> To keep oops from being visible. Might result in bad crashes. >> >> Yes. An alternative is to have the x_oop variables visible at top level, but to put in DEBUG_ONLY(x_oop = NULL). Having the temporary scoped seems cleaner to me, but maybe my sense of style is off here. >> >>> >>> I will refresh the review patch in mlvm. Thank you! >> >> Yes, thanks! >> >> ? John >> _______________________________________________ >> 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 vladimir.kozlov at oracle.com Thu Jul 19 15:11:28 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Jul 2012 15:11:28 -0700 Subject: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: References: <4FFF7983.3050905@oracle.com> <9B5E715C-FD6B-48C3-9A1C-B7FB1581E663@oracle.com> Message-ID: <50088610.6070303@oracle.com> Nice. Vladimir Christian Thalinger wrote: > We forgot to remove the Ricochet Frame code from the sA: > > http://cr.openjdk.java.net/~twisti/7023639/ > > -- Chris > > On Jul 19, 2012, at 11:28 AM, Christian Thalinger wrote: > >> JDK testing found a small bug: >> >> diff --git a/src/share/vm/oops/cpCacheOop.cpp b/src/share/vm/oops/cpCacheOop.cpp >> --- a/src/share/vm/oops/cpCacheOop.cpp >> +++ b/src/share/vm/oops/cpCacheOop.cpp >> @@ -486,7 +486,8 @@ >> // virtual and final so _f2 contains method ptr instead of vtable index >> if (f2_as_vfinal_method() == old_method) { >> // match old_method so need an update >> - set_f2_as_vfinal_method(new_method); >> + // NOTE: can't use set_f2_as_vfinal_method as it asserts on different values >> + _f2 = (intptr_t)new_method; >> if (RC_TRACE_IN_RANGE(0x00100000, 0x00400000)) { >> if (!(*trace_name_printed)) { >> // RC_TRACE_MESG macro has an embedded ResourceMark >> >> I will integrate this one. >> >> -- Chris >> >> On Jul 18, 2012, at 7:10 PM, John Rose wrote: >> >>> On Jul 17, 2012, at 4:04 PM, Christian Thalinger wrote: >>> >>>>> I see in several files next code pattern. Should we call throw_IncompatibleClassChangeError() as we do in other places?: >>>>> >>>>> + if (!EnableInvokeDynamic) { >>>>> + // rewriter does not generate this bytecode >>>>> + __ should_not_reach_here(); >>>>> + return; >>>>> + } >>>> Hmm. This really should not happen and EnableInvokeDynamic is on by default anyway. I doubt someone turns it off. >>> It's now a diagnostic switch. It can be used to verify that an app. is not using 292, which is occasionally helpful. >>> >>>>> constantPoolOop.cpp: >>>>> Why not use guarantee() for bad operants? >>>> Not sure. John? >>> The code in that file uses assert; I think I'm following the existing practice there. The CP code operates after initial verification passes, so assert is suitable, I think. >>> >>>>> Why you need separate scopes in resolve_bootstrap_specifier_at_impl()? >>>> To keep oops from being visible. Might result in bad crashes. >>> Yes. An alternative is to have the x_oop variables visible at top level, but to put in DEBUG_ONLY(x_oop = NULL). Having the temporary scoped seems cleaner to me, but maybe my sense of style is off here. >>> >>>> I will refresh the review patch in mlvm. Thank you! >>> Yes, thanks! >>> >>> ? John >>> _______________________________________________ >>> 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 Jul 19 15:15:46 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Thu, 19 Jul 2012 22:15:46 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: removed Ricochet frame code from SA Message-ID: <20120719221546.77A9E47150@hg.openjdk.java.net> Changeset: f8ac1c76761f Author: twisti Date: 2012-07-19 15:15 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f8ac1c76761f meth-lazy: removed Ricochet frame code from SA ! meth-lazy-7023639.review.patch From john.r.rose at oracle.com Thu Jul 19 17:38:56 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 20 Jul 2012 00:38:56 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: allow non-void LF method to return to void call site Message-ID: <20120720003857.43A1F47153@hg.openjdk.java.net> Changeset: 89a156565b76 Author: jrose Date: 2012-07-19 17:38 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/89a156565b76 meth-lazy: allow non-void LF method to return to void call site ! meth-lazy-7023639.review.patch From dain at iq80.com Thu Jul 19 19:04:39 2012 From: dain at iq80.com (Dain Sundstrom) Date: Thu, 19 Jul 2012 19:04:39 -0700 Subject: MethodHandles and class initialization Message-ID: <15FF6CCE-D6E7-4829-9301-491CF1153381@iq80.com> I have some code that tries to get the value of a static final field using a MethodHandle, and I find that the field is null because the class isn't initialized. Is calling a method handle supposed to cause a class to initialize (run the method)? In a related question, what is the best way to force initialization and when do you do the initialization? in the bootstrap method? BTW, this is on Java7 on OSX. -dain From john.r.rose at oracle.com Thu Jul 19 19:28:18 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 20 Jul 2012 02:28:18 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: add missing int conversions to BMH.bindArgument Message-ID: <20120720022818.80B9B47157@hg.openjdk.java.net> Changeset: 971e1b4846fc Author: jrose Date: 2012-07-19 19:28 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/971e1b4846fc meth-lazy: add missing int conversions to BMH.bindArgument ! meth-lazy-7023639.bmh.patch From john.r.rose at oracle.com Thu Jul 19 19:35:30 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 19 Jul 2012 19:35:30 -0700 Subject: MethodHandles and class initialization In-Reply-To: <15FF6CCE-D6E7-4829-9301-491CF1153381@iq80.com> References: <15FF6CCE-D6E7-4829-9301-491CF1153381@iq80.com> Message-ID: <85C8AFC8-6727-4BB4-AB3B-A5E51AED06F2@oracle.com> On Jul 19, 2012, at 7:04 PM, Dain Sundstrom wrote: > I have some code that tries to get the value of a static final field using a MethodHandle, and I find that the field is null because the class isn't initialized. Is calling a method handle supposed to cause a class to initialize (run the method)? Yes, the behavior of findStaticGetter is based on the getstatic bytecode, which includes (as you expected) the initialization barrier. Same point for putstatic and invokestatic, and REF_newInvokeSpecial (combination of new + ). The JDK 7 implementation has bugs regarding some of these guys. The upcoming integration of "lazy method handles" includes complete coverage for these initialization paths. > In a related question, what is the best way to force initialization and when do you do the initialization? in the bootstrap method? The best way to force initialization of a class is to fetch a static field or call a static method. You can do this with reflection, or (if the above bugs are fixed) via method handles. You can also allocate an instance of the class. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120719/a51d9d2d/attachment.html From john.r.rose at oracle.com Fri Jul 20 01:47:04 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 20 Jul 2012 08:47:04 +0000 Subject: hg: mlvm/mlvm/jdk: meth: integrate possible fix for 7177472 Message-ID: <20120720084705.186FA47165@hg.openjdk.java.net> Changeset: e27e7efee021 Author: jrose Date: 2012-07-20 01:46 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e27e7efee021 meth: integrate possible fix for 7177472 ! meth-7177472.patch ! series From rkennke at redhat.com Fri Jul 20 02:25:13 2012 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 20 Jul 2012 11:25:13 +0200 Subject: State of MLVM and Lambda Message-ID: <1342776313.5305.3.camel@mercury> Hello, Maybe this is a stupid beginner question. I would like to know what is the status of MLVM with respect to project Lambda. Is it possible to build a JVM that has both (has lambda, or parts of it, already been merged into hotspot-comp?)? Is there any overlap between the two, or are they largely independent (MLVM mostly hotspot-centric vs. Lambda mostly javac centric?)? Cheers, Roman From forax at univ-mlv.fr Fri Jul 20 03:32:57 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 20 Jul 2012 12:32:57 +0200 Subject: State of MLVM and Lambda In-Reply-To: <1342776313.5305.3.camel@mercury> References: <1342776313.5305.3.camel@mercury> Message-ID: <500933D9.6060901@univ-mlv.fr> On 07/20/2012 11:25 AM, Roman Kennke wrote: > Hello, > > Maybe this is a stupid beginner question. I would like to know what is > the status of MLVM with respect to project Lambda. Is it possible to > build a JVM that has both (has lambda, or parts of it, already been > merged into hotspot-comp?)? Is there any overlap between the two, or are > they largely independent (MLVM mostly hotspot-centric vs. Lambda mostly > javac centric?)? > > Cheers, > Roman Hi Roman, there are two parts in lambda project, you have lambda and default methods, lambda currently doesn't require runtime support (only javac + JDK) but default methods are resolved by the VM and as far as I know, the default methods part is not merged into hotspot-comp. cheers, R?mi From christian.thalinger at oracle.com Fri Jul 20 14:39:27 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 20 Jul 2012 21:39:27 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: undo changes that caused a problem Message-ID: <20120720213927.AE1D347176@hg.openjdk.java.net> Changeset: 8680e3b4be3b Author: twisti Date: 2012-07-20 14:39 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/8680e3b4be3b meth-lazy: undo changes that caused a problem ! meth-lazy-7023639.review.patch From john.r.rose at oracle.com Sat Jul 21 14:10:31 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 21 Jul 2012 21:10:31 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: remove about 1kLOC more Message-ID: <20120721211032.6E45E47189@hg.openjdk.java.net> Changeset: 4a0cedf169a2 Author: jrose Date: 2012-07-21 14:10 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/4a0cedf169a2 meth-lazy: remove about 1kLOC more + meth-lazy-7023639.rmcode.patch ! series From john.r.rose at oracle.com Sat Jul 21 16:42:27 2012 From: john.r.rose at oracle.com (John Rose) Date: Sat, 21 Jul 2012 16:42:27 -0700 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <50016974.70200@univ-mlv.fr> References: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> <50016974.70200@univ-mlv.fr> Message-ID: <3EEAE008-A6FF-4387-ADA5-48FBADE5F1A5@oracle.com> On Jul 14, 2012, at 5:43 AM, R?mi Forax wrote: > On 07/14/2012 02:02 PM, David Schlosnagle wrote: >> John, > > Hi David, > I hijack the thread ? Thanks for the comments, Remi & David. >> src/share/classes/java/lang/invoke/BoundMethodHandle.java >> >> On lines 131-132: Just out of curiosity, why use pos+1 in one line >> versus 1+pos on the next? Would it be worthwhile to extract pos+1 to a >> local int end to save some bytecode? > Usually you should not care about this kind of change, micro-optimizing > is useless. > Or this code is not called enough and you don't care or this code is hot > and > the JIT will do what should be done and because the JIT may inline > the code of dropParameterTypes and bind(), it will better optimize that you > because it will be able to share more sub-expressions. Remi is correct. >> default case should never be called, so don't 'optimize' for it. Yes. >> >> On line 464: Is there any reason CACHE should not be final? >> static final Map CACHE = new IdentityHashMap<>(); > > this one may be important, static final => const for the VM Yes, that was an oversight. Fixed. >> On lines 473-486: Do the accesses and mutations of CACHE need to be >> thread safe or are the uses assumed to be safe by other means? This was a bug. We have added appropriate synchronization. >> On lines 778-784: Should this use types.charAt(int) rather than >> toCharArray() to copy the array?... > > ...Anyway, the real question here, how often this code will be called and > even if this code is called often, it's perhaps not a bottleneck. It's not a bottleneck. BMH species are few in number. >> Would it be worthwhile for clarity to define constants to represent >> the BaseTypes ('B', 'C', 'D', 'F', 'I', 'J', 'S', 'Z') and ObjectType >> ('L') per JVM spec section 4.3.2 for use throughout these >> java.lang.invoke.* implementation classes (e.g. the various >> switch/case in BoundMethodHandle, and DirectMethodHandle.bindArgument, >> throughout LambdaForm)? I assume that anyone touching this code would >> be familiar with these types so constants may actually reduce clarity >> for some developers. That is my sense of it. The only value to making named constants here would be a slight increase in static checking, but I don't think it's worthwhile. >> src/share/classes/java/lang/invoke/CountingMethodHandle.java >> >> On line 40: Should instance field target be final? >> private final MethodHandle target; > > yes. Even better: During the review I have been finding more dead code to eliminate. This whole class has been finalized, in the sense of "deleted". >> src/share/classes/java/lang/invoke/Invokers.java >> >> On lines 322-326: Is this err.initCause(ex) needed since the cause is >> already passed to the 2 arg InternalError constructor (maybe leftover >> from before the constructor was added in JDK8)? It is a leftover. Thanks for spotting it. >> src/share/classes/java/lang/invoke/MemberName.java >> >> On lines 81-90 there is an implementation of equals(Object), but on >> lines 593-603 there is a commented out implementation of >> equals(Object) and hashCode(). Are the commented out versions for >> future usage? There should probably be an implementation of hashCode() >> consistent with equals, although MemberName may not be used in a hash >> based structure. Also, it might be worthwhile to collocate the "TO BE" >> implementations with near the current ones with a comment. This was an oversight due to some hasty coding. Thanks, fixed. >> >> On lines 268-278: Should the isObjectPublicMethod() method also match >> public Object methods getClass(), notify(), notifyAll(), wait(), >> wait(long), and wait(long, int) or are those not intended to be used? No, those aren't relevant. Since the method is private and its name is long enough already, I'm leaving it as is. Thanks again! ? John From john.r.rose at oracle.com Sat Jul 21 16:45:42 2012 From: john.r.rose at oracle.com (John Rose) Date: Sat, 21 Jul 2012 16:45:42 -0700 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <50067733.7080808@oracle.com> References: <50067733.7080808@oracle.com> Message-ID: <0703FA4C-70CD-4B96-948F-785D1EF614A7@oracle.com> On Jul 18, 2012, at 1:43 AM, Aleksey Shipilev wrote: > This feels outright wrong: > > + static Map CACHE = new IdentityHashMap<>(); > I couple of questions pops out in my mind: > 1. Is this code supposed to be thread-safe? It is then wrong to use > unguarded IdentityHashMap without external synchronization. > 2. Do we really need a second .get() check, if code is not thread-safe > anyway? This code allows two threads to call put() on the same key anyway. > 3. Do the $types *need* to be interned? Or is this the premature > optimization (gone wrong, btw)? You are right on all points. Fixed. > I would rather like to see CHM.putIfAbsent()-based cache on plain > non-interned strings there. Even if interned strings are required, we > could intern them on successful map update, not every time we look up > the key. Yes. Using a IdentityHashMap here is an anti-pattern; sorry to propagate the bad example. Thanks, ? John From john.r.rose at oracle.com Sat Jul 21 16:50:45 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 21 Jul 2012 23:50:45 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: incorporate review comments Message-ID: <20120721235045.ED1224718A@hg.openjdk.java.net> Changeset: 905bcd21d2bb Author: jrose Date: 2012-07-21 16:50 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/905bcd21d2bb meth-lazy: incorporate review comments ! meth-lazy-7023639.rmcode.patch From john.r.rose at oracle.com Sat Jul 21 16:55:24 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 21 Jul 2012 23:55:24 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: consolidate changes made during review Message-ID: <20120721235524.366C14718B@hg.openjdk.java.net> Changeset: 3b3f4347ab7e Author: jrose Date: 2012-07-21 16:55 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/3b3f4347ab7e meth-lazy: consolidate changes made during review - meth-lazy-7023639.bmh.patch - meth-lazy-7023639.init.patch + meth-lazy-7023639.review.patch - meth-lazy-7023639.rmcode.patch ! series From john.r.rose at oracle.com Sat Jul 21 17:16:02 2012 From: john.r.rose at oracle.com (John Rose) Date: Sat, 21 Jul 2012 17:16:02 -0700 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> References: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> Message-ID: <56A27E47-79F2-4414-A7BF-458767EDB163@oracle.com> On Jul 13, 2012, at 2:41 AM, John Rose wrote: > Here is that webrev: > http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.00/ > > These are the changes to JDK code that accompany the JVM changes already under review. I have updated both webrevs to their final contents, as follows: http://cr.openjdk.java.net/~jrose/7023639/webrev.01/ http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.01/ In the same folder are incremental webrevs, for the record. Thanks to all reviewers for their help. ? John P.S. If there's something you don't like in one of the files, let us know. As I noted before, we can (and will) roll more adjustments into the next push. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120721/88fd31b3/attachment.html From henri.gomez at gmail.com Sun Jul 22 02:38:53 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sun, 22 Jul 2012 11:38:53 +0200 Subject: build error on OSX Message-ID: Hi to all, Even using Java 8 for building MLVM, using stephen scripts or my own, build failed : # Running javac: 43 files; in /Users/henri/Downloads/mlvm/sources/jdk/make/java/invoke /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar -jar /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar -Xlint:-path -source 7 -target 7 -encoding ascii -Xbootclasspath:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes -sourcepath /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/gensrc:::/Users/henri/Downloads/mlvm/sources/jdk/src/macosx/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/solaris/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/share/classes -d /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes @/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/tmp/java/java.lang.invoke/.classes.list.filtered ../../../src/share/classes/java/lang/invoke/MethodType.java:996: error: cannot find symbol private final ConcurrentHashMap map = new ConcurrentHashMap(); ^ symbol: class ConcurrentHashMap location: class WeakInternSet ../../../src/share/classes/java/lang/invoke/MethodType.java:996: error: cannot find symbol private final ConcurrentHashMap map = new ConcurrentHashMap(); ^ symbol: class ConcurrentHashMap location: class WeakInternSet 2 errors make[4]: *** [.compile.classlist] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [jdk-build] Error 2 make: *** [build_product_image] Error 2 *** create symbolic link to last build and persist 1.8.0_00-mlvm-2012_07_22.jdk into .last_build build/macosx-x86_64/j2sdk-bundle/jdk1.8.0.jdk/Contents/Home/bin/java does not exist, rebuild MLVM with ./update.sh Any ideas ? Thanks From forax at univ-mlv.fr Sun Jul 22 06:46:20 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 22 Jul 2012 15:46:20 +0200 Subject: build error on OSX In-Reply-To: References: Message-ID: <500C042C.50500@univ-mlv.fr> On 07/22/2012 11:38 AM, Henri Gomez wrote: > Hi to all, > > Even using Java 8 for building MLVM, using stephen scripts or my own, > build failed : > > > # Running javac: 43 files; in > /Users/henri/Downloads/mlvm/sources/jdk/make/java/invoke > /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/bin/java > -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput > -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m > -XX:MaxPermSize=160m > -Xbootclasspath/p:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar > -jar /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar > -Xlint:-path -source 7 -target 7 -encoding ascii > -Xbootclasspath:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes > -sourcepath /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/gensrc:::/Users/henri/Downloads/mlvm/sources/jdk/src/macosx/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/solaris/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/share/classes > -d /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes > @/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/tmp/java/java.lang.invoke/.classes.list.filtered > ../../../src/share/classes/java/lang/invoke/MethodType.java:996: > error: cannot find symbol > private final ConcurrentHashMap map = new > ConcurrentHashMap(); > ^ > symbol: class ConcurrentHashMap > location: class WeakInternSet > ../../../src/share/classes/java/lang/invoke/MethodType.java:996: > error: cannot find symbol > private final ConcurrentHashMap map = new > ConcurrentHashMap(); > ^ > symbol: class ConcurrentHashMap > location: class WeakInternSet > 2 errors > make[4]: *** [.compile.classlist] Error 1 > make[3]: *** [all] Error 1 > make[2]: *** [all] Error 1 > make[1]: *** [jdk-build] Error 2 > make: *** [build_product_image] Error 2 > > *** create symbolic link to last build and persist > 1.8.0_00-mlvm-2012_07_22.jdk into .last_build > > build/macosx-x86_64/j2sdk-bundle/jdk1.8.0.jdk/Contents/Home/bin/java > does not exist, rebuild MLVM with ./update.sh > > Any ideas ? add import java.util.concurrent.ConcurrentHashMap to java/lang/invoke/MethodType.java. > > Thanks cheers, R?mi From henri.gomez at gmail.com Sun Jul 22 10:25:16 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sun, 22 Jul 2012 19:25:16 +0200 Subject: build error on OSX In-Reply-To: <500C042C.50500@univ-mlv.fr> References: <500C042C.50500@univ-mlv.fr> Message-ID: <09568B9D-460A-4527-ACAD-DC3A19207868@gmail.com> Hum, commited without this import ? Le 22 juil. 2012 ? 15:46, R?mi Forax a ?crit : > On 07/22/2012 11:38 AM, Henri Gomez wrote: >> Hi to all, >> >> Even using Java 8 for building MLVM, using stephen scripts or my own, >> build failed : >> >> >> # Running javac: 43 files; in >> /Users/henri/Downloads/mlvm/sources/jdk/make/java/invoke >> /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/bin/java >> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput >> -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m >> -XX:MaxPermSize=160m >> -Xbootclasspath/p:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar >> -jar /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar >> -Xlint:-path -source 7 -target 7 -encoding ascii >> -Xbootclasspath:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes >> -sourcepath /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/gensrc:::/Users/henri/Downloads/mlvm/sources/jdk/src/macosx/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/solaris/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/share/classes >> -d /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes >> @/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/tmp/java/java.lang.invoke/.classes.list.filtered >> ../../../src/share/classes/java/lang/invoke/MethodType.java:996: >> error: cannot find symbol >> private final ConcurrentHashMap map = new >> ConcurrentHashMap(); >> ^ >> symbol: class ConcurrentHashMap >> location: class WeakInternSet >> ../../../src/share/classes/java/lang/invoke/MethodType.java:996: >> error: cannot find symbol >> private final ConcurrentHashMap map = new >> ConcurrentHashMap(); >> ^ >> symbol: class ConcurrentHashMap >> location: class WeakInternSet >> 2 errors >> make[4]: *** [.compile.classlist] Error 1 >> make[3]: *** [all] Error 1 >> make[2]: *** [all] Error 1 >> make[1]: *** [jdk-build] Error 2 >> make: *** [build_product_image] Error 2 >> >> *** create symbolic link to last build and persist >> 1.8.0_00-mlvm-2012_07_22.jdk into .last_build >> >> build/macosx-x86_64/j2sdk-bundle/jdk1.8.0.jdk/Contents/Home/bin/java >> does not exist, rebuild MLVM with ./update.sh >> >> Any ideas ? > > add import java.util.concurrent.ConcurrentHashMap to > java/lang/invoke/MethodType.java. >> >> Thanks > > cheers, > R?mi > > _______________________________________________ > 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 Sun Jul 22 10:30:49 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sun, 22 Jul 2012 19:30:49 +0200 Subject: build error on OSX In-Reply-To: <09568B9D-460A-4527-ACAD-DC3A19207868@gmail.com> References: <500C042C.50500@univ-mlv.fr> <09568B9D-460A-4527-ACAD-DC3A19207868@gmail.com> Message-ID: <500C38C9.60000@univ-mlv.fr> On 07/22/2012 07:25 PM, Henri Gomez wrote: > Hum, commited without this import ? maybe lost in the patch queue ?? R?mi > Le 22 juil. 2012 ? 15:46, R?mi Forax a ?crit : > >> On 07/22/2012 11:38 AM, Henri Gomez wrote: >>> Hi to all, >>> >>> Even using Java 8 for building MLVM, using stephen scripts or my own, >>> build failed : >>> >>> >>> # Running javac: 43 files; in >>> /Users/henri/Downloads/mlvm/sources/jdk/make/java/invoke >>> /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/bin/java >>> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput >>> -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m >>> -XX:MaxPermSize=160m >>> -Xbootclasspath/p:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar >>> -jar /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar >>> -Xlint:-path -source 7 -target 7 -encoding ascii >>> -Xbootclasspath:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes >>> -sourcepath /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/gensrc:::/Users/henri/Downloads/mlvm/sources/jdk/src/macosx/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/solaris/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/share/classes >>> -d /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes >>> @/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/tmp/java/java.lang.invoke/.classes.list.filtered >>> ../../../src/share/classes/java/lang/invoke/MethodType.java:996: >>> error: cannot find symbol >>> private final ConcurrentHashMap map = new >>> ConcurrentHashMap(); >>> ^ >>> symbol: class ConcurrentHashMap >>> location: class WeakInternSet >>> ../../../src/share/classes/java/lang/invoke/MethodType.java:996: >>> error: cannot find symbol >>> private final ConcurrentHashMap map = new >>> ConcurrentHashMap(); >>> ^ >>> symbol: class ConcurrentHashMap >>> location: class WeakInternSet >>> 2 errors >>> make[4]: *** [.compile.classlist] Error 1 >>> make[3]: *** [all] Error 1 >>> make[2]: *** [all] Error 1 >>> make[1]: *** [jdk-build] Error 2 >>> make: *** [build_product_image] Error 2 >>> >>> *** create symbolic link to last build and persist >>> 1.8.0_00-mlvm-2012_07_22.jdk into .last_build >>> >>> build/macosx-x86_64/j2sdk-bundle/jdk1.8.0.jdk/Contents/Home/bin/java >>> does not exist, rebuild MLVM with ./update.sh >>> >>> Any ideas ? >> add import java.util.concurrent.ConcurrentHashMap to >> java/lang/invoke/MethodType.java. >>> Thanks >> cheers, >> R?mi >> >> _______________________________________________ >> 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 henri.gomez at gmail.com Sun Jul 22 12:54:47 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Sun, 22 Jul 2012 21:54:47 +0200 Subject: build error on OSX In-Reply-To: <500C38C9.60000@univ-mlv.fr> References: <500C042C.50500@univ-mlv.fr> <09568B9D-460A-4527-ACAD-DC3A19207868@gmail.com> <500C38C9.60000@univ-mlv.fr> Message-ID: 2012/7/22 R?mi Forax : > On 07/22/2012 07:25 PM, Henri Gomez wrote: >> Hum, commited without this import ? > > maybe lost in the patch queue ?? I took a look at patches and there is no ConcurrentHashMap here ;( From john.r.rose at oracle.com Sun Jul 22 16:01:40 2012 From: john.r.rose at oracle.com (John Rose) Date: Sun, 22 Jul 2012 16:01:40 -0700 Subject: build error on OSX In-Reply-To: References: <500C042C.50500@univ-mlv.fr> <09568B9D-460A-4527-ACAD-DC3A19207868@gmail.com> <500C38C9.60000@univ-mlv.fr> Message-ID: I think the patch after meth-lazy needs rebasing. Just comment it out in the series file for now. -- John (on my iPhone) On Jul 22, 2012, at 12:54 PM, Henri Gomez wrote: > 2012/7/22 R?mi Forax : >> On 07/22/2012 07:25 PM, Henri Gomez wrote: >>> Hum, commited without this import ? >> >> maybe lost in the patch queue ?? > > I took a look at patches and there is no ConcurrentHashMap here ;( > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From henri.gomez at gmail.com Mon Jul 23 00:47:17 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Jul 2012 09:47:17 +0200 Subject: build error on OSX In-Reply-To: References: <500C042C.50500@univ-mlv.fr> <09568B9D-460A-4527-ACAD-DC3A19207868@gmail.com> <500C38C9.60000@univ-mlv.fr> Message-ID: > I think the patch after meth-lazy needs rebasing. Just comment it out in the series file for now. how could I comment it ? From rkennke at redhat.com Mon Jul 23 01:14:06 2012 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 23 Jul 2012 10:14:06 +0200 Subject: build error on OSX In-Reply-To: References: <500C042C.50500@univ-mlv.fr> <09568B9D-460A-4527-ACAD-DC3A19207868@gmail.com> <500C38C9.60000@univ-mlv.fr> Message-ID: <1343031246.11458.2.camel@mercury> Am Montag, den 23.07.2012, 09:47 +0200 schrieb Henri Gomez: > > I think the patch after meth-lazy needs rebasing. Just comment it out in the series file for now. > > how could I comment it ? Edit the series file with a text editor and prefix the line that shows the name of that patch with # . Roman From henri.gomez at gmail.com Mon Jul 23 01:21:27 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Mon, 23 Jul 2012 10:21:27 +0200 Subject: build error on OSX In-Reply-To: <1343031246.11458.2.camel@mercury> References: <500C042C.50500@univ-mlv.fr> <09568B9D-460A-4527-ACAD-DC3A19207868@gmail.com> <500C38C9.60000@univ-mlv.fr> <1343031246.11458.2.camel@mercury> Message-ID: > Edit the series file with a text editor and prefix the line that shows > the name of that patch with # . Thanks Roman Since it won't be in phase with mlvm mercurial repo, I should patch it after syncing, right ? From aleksey.shipilev at oracle.com Mon Jul 23 02:27:30 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 23 Jul 2012 13:27:30 +0400 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <0703FA4C-70CD-4B96-948F-785D1EF614A7@oracle.com> References: <50067733.7080808@oracle.com> <0703FA4C-70CD-4B96-948F-785D1EF614A7@oracle.com> Message-ID: <500D1902.4060803@oracle.com> On 07/22/2012 03:45 AM, John Rose wrote: > On Jul 18, 2012, at 1:43 AM, Aleksey Shipilev wrote: > Yes. Thanks John. I'm having a glance over the fix in new webrev, and this feels even worse: + private static SpeciesData get(String types) { + // Acquire cache lock for query. + SpeciesData d = lookupCache(types); + if (!d.isPlaceholder()) + return d; + Class cbmh; + synchronized (d) { + // Use synch. on the placeholder to prevent multiple instantiation of one species. + // Creating this class forces a recursive call to getForClass. + cbmh = Factory.generateConcreteBMHClass(types); + } + // Reacquire cache lock. + d = lookupCache(types); + // Class loading must have upgraded the cache. + assert(d != null && !d.isPlaceholder()); + return d; + } + static SpeciesData getForClass(String types, Class clazz) { + // clazz is a new class which is initializing its SPECIES_DATA field + return updateCache(types, new SpeciesData(types, clazz)); + } + private static synchronized SpeciesData lookupCache(String types) { + SpeciesData d = CACHE.get(types); + if (d != null) return d; + d = new SpeciesData(types); + assert(d.isPlaceholder()); + CACHE.put(types, d); + return d; + } + private static synchronized SpeciesData updateCache(String types, SpeciesData d) { + SpeciesData d2; + assert((d2 = CACHE.get(types)) == null || d2.isPlaceholder()); + assert(!d.isPlaceholder()); + CACHE.put(types, d); + return d; + } Global synchronization is the performance smell, and this looks to be potential scalability bottleneck (it sends shivers down my spine every time I see "static synchronized" in the same line. That is not to mention synchronizing on placeholder looks suspicious and error-prone. Do you need help rewriting this with CHM? -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120723/fad99c5a/signature.asc From aleksey.shipilev at oracle.com Mon Jul 23 03:01:16 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 23 Jul 2012 14:01:16 +0400 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <56A27E47-79F2-4414-A7BF-458767EDB163@oracle.com> References: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> <56A27E47-79F2-4414-A7BF-458767EDB163@oracle.com> Message-ID: <500D20EC.5020607@oracle.com> On 07/22/2012 04:16 AM, John Rose wrote: > P.S. If there's something you don't like in one of the files, let us know. > As I noted before, we can (and will) roll more adjustments into the next > push. I have a question about $PREPARED_FORMS there. It looks like it is not used anywhere in the code, should we eliminate it whatsoever? If not, then I have trouble understanding if we need to explicitly override CHM defaults, especially concurrency level there. (I know Doug pushes back on specialized constructors in CHMv8 because some of the parameters are meaningless there). -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120723/0e62f19f/signature.asc From christian.thalinger at oracle.com Mon Jul 23 10:13:08 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 23 Jul 2012 17:13:08 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: fixed 32-bit SPARC C1 problem Message-ID: <20120723171308.CD438471A8@hg.openjdk.java.net> Changeset: a8cb0e14256a Author: twisti Date: 2012-07-23 10:12 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a8cb0e14256a meth-lazy: fixed 32-bit SPARC C1 problem ! meth-lazy-7023639.review.patch From john.r.rose at oracle.com Mon Jul 23 10:43:19 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Mon, 23 Jul 2012 17:43:19 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: consolidate for review Message-ID: <20120723174320.0CEFC471B0@hg.openjdk.java.net> Changeset: b078b2c12089 Author: jrose Date: 2012-07-23 10:36 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b078b2c12089 meth-lazy: consolidate for review ! meth-lazy-7023639.patch - meth-lazy-7023639.review.patch ! series From john.r.rose at oracle.com Mon Jul 23 10:44:20 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Mon, 23 Jul 2012 17:44:20 +0000 Subject: hg: mlvm/mlvm/jdk: meth-lazy: consolidate for review Message-ID: <20120723174420.7403F471B1@hg.openjdk.java.net> Changeset: 0cd0e35d7fe6 Author: jrose Date: 2012-07-23 10:44 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/0cd0e35d7fe6 meth-lazy: consolidate for review ! meth-lazy-7023639.patch - meth-lazy-7023639.review.patch ! series From vladimir.kozlov at oracle.com Mon Jul 23 11:15:35 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 23 Jul 2012 11:15:35 -0700 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <56A27E47-79F2-4414-A7BF-458767EDB163@oracle.com> References: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> <56A27E47-79F2-4414-A7BF-458767EDB163@oracle.com> Message-ID: <500D94C7.4000609@oracle.com> John, Both webrevs point to jdk changes. Where are hotspot changes? Vladimir John Rose wrote: > On Jul 13, 2012, at 2:41 AM, John Rose wrote: > >> Here is that webrev: >> http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.00/ >> >> These are the changes to JDK code that accompany the JVM changes >> already under review. > > I have updated both webrevs to their final contents, as follows: > > http://cr.openjdk.java.net/~jrose/7023639/webrev.01/ > http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.01/ > > In the same folder are incremental webrevs, for the record. > > Thanks to all reviewers for their help. > > ? John > > P.S. If there's something you don't like in one of the files, let us know. > As I noted before, we can (and will) roll more adjustments into the next > push. From john.r.rose at oracle.com Mon Jul 23 11:31:55 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 23 Jul 2012 11:31:55 -0700 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <500D1902.4060803@oracle.com> References: <50067733.7080808@oracle.com> <0703FA4C-70CD-4B96-948F-785D1EF614A7@oracle.com> <500D1902.4060803@oracle.com> Message-ID: <0A3DAA7C-440F-42F3-A794-1654DAF59549@oracle.com> On Jul 23, 2012, at 2:27 AM, Aleksey Shipilev wrote: > Global synchronization is the performance smell, and this looks to be > potential scalability bottleneck (it sends shivers down my spine every > time I see "static synchronized" in the same line. That is not to > mention synchronizing on placeholder looks suspicious and error-prone. I believe the code is correct. The purpose is to load as many distinct "species" of BMH tuples as the application type schema requires. The use of placeholders is patterned after the JVM's internal class loading algorithm. The code does not need to be scalable, because the number of entries in the cache is small (order of 10-100) and scales only with type schema complexity, not workload complexity. So in this case, "static synchronized" is the correct choice. > Do you need help rewriting this with CHM? No, but thanks for the help! ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120723/ef437ceb/attachment.html From john.r.rose at oracle.com Mon Jul 23 12:01:07 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 23 Jul 2012 12:01:07 -0700 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <500D94C7.4000609@oracle.com> References: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> <56A27E47-79F2-4414-A7BF-458767EDB163@oracle.com> <500D94C7.4000609@oracle.com> Message-ID: On Jul 23, 2012, at 11:15 AM, Vladimir Kozlov wrote: > Both webrevs point to jdk changes. Where are hotspot changes? Oops, fixed. Please try again: http://cr.openjdk.java.net/~jrose/7023639/webrev.01/ http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.01/ ? John From vladimir.kozlov at oracle.com Mon Jul 23 16:40:01 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 23 Jul 2012 16:40:01 -0700 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: References: <24BAA67D-6F36-4668-99E0-67532D012A92@oracle.com> <56A27E47-79F2-4414-A7BF-458767EDB163@oracle.com> <500D94C7.4000609@oracle.com> Message-ID: <500DE0D1.4070704@oracle.com> I think it is good. Vladimir John Rose wrote: > On Jul 23, 2012, at 11:15 AM, Vladimir Kozlov wrote: > >> Both webrevs point to jdk changes. Where are hotspot changes? > > Oops, fixed. Please try again: > > http://cr.openjdk.java.net/~jrose/7023639/webrev.01/ > http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.01/ > > ? John From aleksey.shipilev at oracle.com Tue Jul 24 02:55:58 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 24 Jul 2012 13:55:58 +0400 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <0A3DAA7C-440F-42F3-A794-1654DAF59549@oracle.com> References: <50067733.7080808@oracle.com> <0703FA4C-70CD-4B96-948F-785D1EF614A7@oracle.com> <500D1902.4060803@oracle.com> <0A3DAA7C-440F-42F3-A794-1654DAF59549@oracle.com> Message-ID: <500E712E.5030502@oracle.com> On 07/23/2012 10:31 PM, John Rose wrote: > On Jul 23, 2012, at 2:27 AM, Aleksey Shipilev wrote: > The code does not need to be scalable, because the number of entries in > the cache is small (order of 10-100) and scales only with type schema > complexity, not workload complexity. If I had a nickel... Not sure if this logic is applicable in this particular case. This is the potential "performance cliff" you are eager to get rid of with new implementation. Given enough users and applications make use of this code, someone will eventually step and burn on this. This wishful thinking "it's okay to use synchronized here, because this couldn't possibly get contended" lead to many beautiful scalability bottlenecks throughout the JDK. While it is usually a simple thing to fix, I'm keen on not allowing to make the same mistakes over and over again. > So in this case, "static synchronized" is the correct choice. I shall wait for mainline integration to complete and then try to run the microbenchmarks against the new backend; will see if this potential issue is the practical one. -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120724/3bfefaff/signature.asc From aleksey.shipilev at oracle.com Tue Jul 24 06:36:03 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 24 Jul 2012 17:36:03 +0400 Subject: MethodHandle.bindTo() only for reference types? Message-ID: <500EA4C3.5010105@oracle.com> Hi, I wonder if anyone could point to the explanation why MH.bindTo() is accepting only reference types? This behavior seems surprising for newcomers like me, mostly because similar API accepts primitive types. For one, given: public static void foo(int i); ...and the MethodHandle mh referring to it, I can do: MethodHandle mh2 = MethodHandles.insertArguments(mh, 0, (int)someInt) ...but this one is prohibited: MethodHandle mh2 = mh.bindTo((int)someInt); Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120724/f7493c69/signature.asc From christian.thalinger at oracle.com Tue Jul 24 08:15:26 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 24 Jul 2012 08:15:26 -0700 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: <500E712E.5030502@oracle.com> References: <50067733.7080808@oracle.com> <0703FA4C-70CD-4B96-948F-785D1EF614A7@oracle.com> <500D1902.4060803@oracle.com> <0A3DAA7C-440F-42F3-A794-1654DAF59549@oracle.com> <500E712E.5030502@oracle.com> Message-ID: On Jul 24, 2012, at 2:55 AM, Aleksey Shipilev wrote: > On 07/23/2012 10:31 PM, John Rose wrote: >> On Jul 23, 2012, at 2:27 AM, Aleksey Shipilev wrote: >> The code does not need to be scalable, because the number of entries in >> the cache is small (order of 10-100) and scales only with type schema >> complexity, not workload complexity. > > If I had a nickel... > > Not sure if this logic is applicable in this particular case. This is > the potential "performance cliff" you are eager to get rid of with new > implementation. No it's not. We know exactly what causes the performance cliff. It's a completely unrelated issue in the VM. -- Chris > Given enough users and applications make use of this > code, someone will eventually step and burn on this. > > This wishful thinking "it's okay to use synchronized here, because this > couldn't possibly get contended" lead to many beautiful scalability > bottlenecks throughout the JDK. While it is usually a simple thing to > fix, I'm keen on not allowing to make the same mistakes over and over again. > >> So in this case, "static synchronized" is the correct choice. > > I shall wait for mainline integration to complete and then try to run > the microbenchmarks against the new backend; will see if this potential > issue is the practical one. > > -Aleksey. > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From aleksey.shipilev at oracle.com Tue Jul 24 10:23:27 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 24 Jul 2012 21:23:27 +0400 Subject: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code In-Reply-To: References: <50067733.7080808@oracle.com> <0703FA4C-70CD-4B96-948F-785D1EF614A7@oracle.com> <500D1902.4060803@oracle.com> <0A3DAA7C-440F-42F3-A794-1654DAF59549@oracle.com> <500E712E.5030502@oracle.com> Message-ID: <500EDA0F.9050902@oracle.com> On 07/24/2012 07:15 PM, Christian Thalinger wrote: >> Not sure if this logic is applicable in this particular case. This is >> the potential "performance cliff" you are eager to get rid of with new >> implementation. > > No it's not. We know exactly what causes the performance cliff. It's a completely unrelated issue in the VM. Sorry for misguided definition there, thought quoting does the trick for me. I was meant to say that the scalability bottlenecks like these pop out quickly, unexpected and hit hard. The difference between single-threaded and two-threaded versions could be so dramatic, so you can easily say it goes down the sink. It's inconvenient to fix one "cliff" and introduce the other, albeit "completely unrelated". -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120724/811e15f7/signature.asc From szegedia at gmail.com Tue Jul 24 11:09:18 2012 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 24 Jul 2012 11:09:18 -0700 Subject: MethodHandle.bindTo() only for reference types? In-Reply-To: <500EA4C3.5010105@oracle.com> References: <500EA4C3.5010105@oracle.com> Message-ID: The "bind" operation is traditionally used for taking an instance method (that takes an object instance as its 0th argument), and binding it to a specific instance. It's an admittedly minor semantic point. I don't think technically there'd be a difficulty in having it work on primitives, it's just that it ain't the intent; you still use insertArguments() for uses that are not semantically "bind"s. Attila. On Tue, Jul 24, 2012 at 6:36 AM, Aleksey Shipilev wrote: > Hi, > > I wonder if anyone could point to the explanation why MH.bindTo() is > accepting only reference types? This behavior seems surprising for > newcomers like me, mostly because similar API accepts primitive types. > For one, given: > > public static void foo(int i); > > ...and the MethodHandle mh referring to it, I can do: > MethodHandle mh2 = MethodHandles.insertArguments(mh, 0, (int)someInt) > > ...but this one is prohibited: > MethodHandle mh2 = mh.bindTo((int)someInt); > > Thanks, > -Aleksey. > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From john.r.rose at oracle.com Tue Jul 24 12:02:18 2012 From: john.r.rose at oracle.com (John Rose) Date: Tue, 24 Jul 2012 12:02:18 -0700 Subject: MethodHandle.bindTo() only for reference types? In-Reply-To: References: <500EA4C3.5010105@oracle.com> Message-ID: <7856A2AC-5EAA-4E8B-9485-369268773482@oracle.com> On Jul 24, 2012, at 11:09 AM, Attila Szegedi wrote: > I don't think technically there'd be a difficulty in having it > work on primitives, it's just that it ain't the intent; you still use > insertArguments() for uses that are not semantically "bind"s. MethodHandle.bind is a less-general primitive. The general API is insertArguments. Good 292 support for primitives requires a signature-polymorphic API. Therefore, we have been considering adding something like this, to fill functionality not covered by bind and insertArguments: class MethodHandle { /** Binds the given argument(s) to the method handle, but does not invoke it. * Arguments are not boxed, but rather passed in a signature-polymorphic call. * Requires an exact match to the corresponding leading parameter types. * Returns a method handle which accepts any remaining arguments, * and invokes the original on the combined argument lists. * Equivalent to insertArguments(this, 0, args), but may be more efficient. * Equivalent to this.bind(args[0]), but may be more efficient. */ public final native Object invokePartial(Object? args) throws Throwable; } If we do, we will first experiment internally with it (as a non-public API). ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120724/fd58ac55/attachment.html From forax at univ-mlv.fr Tue Jul 24 14:22:09 2012 From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=) Date: Tue, 24 Jul 2012 23:22:09 +0200 Subject: MethodHandle.bindTo() only for reference types? In-Reply-To: <7856A2AC-5EAA-4E8B-9485-369268773482@oracle.com> References: <500EA4C3.5010105@oracle.com> <7856A2AC-5EAA-4E8B-9485-369268773482@oracle.com> Message-ID: <500F1201.1050308@univ-mlv.fr> On 07/24/2012 09:02 PM, John Rose wrote: > On Jul 24, 2012, at 11:09 AM, Attila Szegedi wrote: > >> I don't think technically there'd be a difficulty in having it >> work on primitives, it's just that it ain't the intent; you still use >> insertArguments() for uses that are not semantically "bind"s. > > MethodHandle.bind is a less-general primitive. The general API is > insertArguments. > > Good 292 support for primitives requires a signature-polymorphic API. > > Therefore, we have been considering adding something like this, to > fill functionality not covered by bind and insertArguments: > > class MethodHandle { > /** Binds the given argument(s) to the method handle, but does not > invoke it. > * Arguments are not boxed, but rather passed in a > signature-polymorphic call. > * Requires an exact match to the corresponding leading parameter types. > * Returns a method handle which accepts any remaining arguments, > * and invokes the original on the combined argument lists. > * Equivalent to insertArguments(this, 0, args), but may be more efficient. > * Equivalent to this.bind(args[0]), but may be more efficient. > */ > public final native MethodHandle invokePartial(Object? args) throws > Throwable; > } > > If we do, we will first experiment internally with it (as a non-public > API). invokePartial is in fact, invokedynamic + insertArguments + insertArguments (to insert 0) + asType(asVarargCollector) + escape analysis (to remove the array allocation and boxing). I would prefer a way to gently ask the compiler to substitute a classical Java call to an invokedynamic one. The question is: are VMs able to do the escape analysis here or not. BTW, invokePartial is important because it is the primitive needed when you want to create a lambda that capture some values from the scope so even Java will use it. > > ? John R?mi From mroos at roos.com Tue Jul 24 19:26:19 2012 From: mroos at roos.com (Mark Roos) Date: Tue, 24 Jul 2012 19:26:19 -0700 Subject: RE Lambda Forms the Sequel Message-ID: >From John on the HotSpot list The new Lambda Form framework is about to be integrated. This a key foundation stone for optimizing dynamic languages. On this foundation, we want to build a robustly performant and portable implementation of JSR 292, to support our current and future set of great JVM languages, and to provide a flexible framework for code management. So for those of us not at Oracle but would like to get some in depth knowledge on how to use 292 to its max, any thoughts of a Total Immersion Workshop for 292? I would gladly pay $$ for that. regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120724/e78f3a68/attachment.html From christian.thalinger at oracle.com Wed Jul 25 15:19:31 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 25 Jul 2012 22:19:31 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-lazy: last minute fixes Message-ID: <20120725221932.CB6C347201@hg.openjdk.java.net> Changeset: 6ca8164f788f Author: twisti Date: 2012-07-25 15:19 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/6ca8164f788f meth-lazy: last minute fixes ! meth-lazy-7023639.patch From aleksey.shipilev at oracle.com Thu Jul 26 02:50:10 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 26 Jul 2012 13:50:10 +0400 Subject: MethodHandle.bindTo() only for reference types? In-Reply-To: <7856A2AC-5EAA-4E8B-9485-369268773482@oracle.com> References: <500EA4C3.5010105@oracle.com> <7856A2AC-5EAA-4E8B-9485-369268773482@oracle.com> Message-ID: <501112D2.4060505@oracle.com> Hi John, On 07/24/2012 11:02 PM, John Rose wrote: > On Jul 24, 2012, at 11:09 AM, Attila Szegedi wrote: > MethodHandle.bind is a less-general primitive. The general API is > insertArguments. > > Good 292 support for primitives requires a signature-polymorphic API. > > Therefore, we have been considering adding something like this, to fill > functionality not covered by bind and insertArguments: Thanks for thinking forward on this. But let's get back to the original issue: inconsistent API between MH.bindTo() and MHs.insertArguments(). If the latter boxes primitive values, why not to allow the former to do the same? Albeit it is not "a good support for primitives", but this is the consistency improvement. Thanks, Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120726/53d211a6/signature.asc From forax at univ-mlv.fr Thu Jul 26 03:03:17 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 26 Jul 2012 12:03:17 +0200 Subject: MethodHandle.bindTo() only for reference types? In-Reply-To: <501112D2.4060505@oracle.com> References: <500EA4C3.5010105@oracle.com> <7856A2AC-5EAA-4E8B-9485-369268773482@oracle.com> <501112D2.4060505@oracle.com> Message-ID: <501115E5.2070606@univ-mlv.fr> On 07/26/2012 11:50 AM, Aleksey Shipilev wrote: > Hi John, > > On 07/24/2012 11:02 PM, John Rose wrote: >> On Jul 24, 2012, at 11:09 AM, Attila Szegedi wrote: >> MethodHandle.bind is a less-general primitive. The general API is >> insertArguments. >> >> Good 292 support for primitives requires a signature-polymorphic API. >> >> Therefore, we have been considering adding something like this, to fill >> functionality not covered by bind and insertArguments: > Thanks for thinking forward on this. But let's get back to the original > issue: inconsistent API between MH.bindTo() and MHs.insertArguments(). > If the latter boxes primitive values, why not to allow the former to do > the same? Albeit it is not "a good support for primitives", but this is > the consistency improvement. The idea that that bindTo() should be used as Attila said when you want to de-virtualize a method by fixing the receiver to a particular object. The idea is that when you see bindTo() in a code you know the intent of the programmer without having to track precisely which parameter is bound with which value. > > Thanks, > Aleksey. cheers, R?mi From lukas.stadler at jku.at Thu Jul 26 08:13:57 2012 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Thu, 26 Jul 2012 15:13:57 +0000 Subject: hg: mlvm/mlvm/hotspot: 2 new changesets Message-ID: <20120726151358.57C7A4721B@hg.openjdk.java.net> Changeset: b4050524c2ff Author: Lukas Stadler Date: 2012-07-26 17:10 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b4050524c2ff coro: updated patch, new coro-simple version - coro-meth.patch + coro-simple.patch - coro-standalone.patch ! coro.patch ! series Changeset: 3bd88fb254b4 Author: Lukas Stadler Date: 2012-07-26 17:12 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/3bd88fb254b4 merge From lukas.stadler at jku.at Thu Jul 26 08:16:32 2012 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Thu, 26 Jul 2012 15:16:32 +0000 Subject: hg: mlvm/mlvm/jdk: 2 new changesets Message-ID: <20120726151633.029C74721C@hg.openjdk.java.net> Changeset: 1bb873eba051 Author: Lukas Stadler Date: 2012-07-25 14:19 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/1bb873eba051 fix meth-7177472.patch for recent changes in meth-lazy-7023639.patch ! meth-7177472.patch Changeset: 90c60ec5aba4 Author: Lukas Stadler Date: 2012-07-26 17:14 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/90c60ec5aba4 coro: updated patch, new coro-simple version + coro-simple.patch ! series From forax at univ-mlv.fr Fri Jul 27 09:44:09 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 27 Jul 2012 18:44:09 +0200 Subject: Backport 2.0 RC Message-ID: <5012C559.4030300@univ-mlv.fr> As traditionally for the JVM Summit, I'm please to announce a new version of the JSR 292 backport, http://code.google.com/p/jvm-language-runtime/downloads/list This version as some speed improvements and numerous bug fixes thanks to the Nashorn Team. I'm still interested by any report of your favorite language running with the backport, Jochen?, Mark?, Duncan?, Charles*? or anyone that develop a language runtime. cheers, R?mi * can I also beg for a special voodoo option of the CLI of JRuby to force invokedynamic bytecode on a 1.6 VM ? From blackdrag at gmx.org Fri Jul 27 10:56:40 2012 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 27 Jul 2012 19:56:40 +0200 Subject: Backport 2.0 RC In-Reply-To: <5012C559.4030300@univ-mlv.fr> References: <5012C559.4030300@univ-mlv.fr> Message-ID: <5012D658.8050301@gmx.org> Am 27.07.2012 18:44, schrieb R?mi Forax: > As traditionally for the JVM Summit, > I'm please to announce a new version of the JSR 292 backport, > http://code.google.com/p/jvm-language-runtime/downloads/list > > This version as some speed improvements and numerous bug fixes thanks to > the Nashorn Team. > > I'm still interested by any report of your favorite language running > with the backport, > Jochen?, Mark?, Duncan?, Charles*? or anyone that develop a language > runtime. The Groovy plans for invokedynamic are that version 3 of Groovy, coming next year, will use invokedynamic per default and the backport will be then used as a way to make it run on earlier VMs. I haven't really tried it out yet, instead in Groovy 2.0.1 we support invokedynamic as a Groovy VM plugin for jdk7. But I intend to test your backport against our call site caching after the summit.... well... I will be in Santa Clara on Sunday already if you want we could meet up and try making an integration of your backport. A meeting with whoever wants to participate in the invokedynamic workshop to speak what to do there is also something that could be done. Otherwise I will have to think of it all by myself. bye blackdrag -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org From forax at univ-mlv.fr Fri Jul 27 11:59:42 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 27 Jul 2012 20:59:42 +0200 Subject: Backport 2.0 RC In-Reply-To: <5012D658.8050301@gmx.org> References: <5012C559.4030300@univ-mlv.fr> <5012D658.8050301@gmx.org> Message-ID: <5012E51E.6040200@univ-mlv.fr> On 07/27/2012 07:56 PM, Jochen Theodorou wrote: > Am 27.07.2012 18:44, schrieb R?mi Forax: >> As traditionally for the JVM Summit, >> I'm please to announce a new version of the JSR 292 backport, >> http://code.google.com/p/jvm-language-runtime/downloads/list >> >> This version as some speed improvements and numerous bug fixes thanks to >> the Nashorn Team. >> >> I'm still interested by any report of your favorite language running >> with the backport, >> Jochen?, Mark?, Duncan?, Charles*? or anyone that develop a language >> runtime. > The Groovy plans for invokedynamic are that version 3 of Groovy, coming > next year, will use invokedynamic per default and the backport will be > then used as a way to make it run on earlier VMs. I haven't really tried > it out yet, instead in Groovy 2.0.1 we support invokedynamic as a Groovy > VM plugin for jdk7. But I intend to test your backport against our call > site caching after the summit.... > > well... I will be in Santa Clara on Sunday already if you want we could > meet up and try making an integration of your backport. A meeting with > whoever wants to participate in the invokedynamic workshop to speak what > to do there is also something that could be done. Otherwise I will have > to think of it all by myself. My plane will land Sunday late in the evening, so I think it's better to try to figure out that during the summit. > > bye blackdrag > C U soon, R?mi From mroos at roos.com Fri Jul 27 12:49:40 2012 From: mroos at roos.com (Mark Roos) Date: Fri, 27 Jul 2012 12:49:40 -0700 Subject: Backport 2.0 RC In-Reply-To: <5012C559.4030300@univ-mlv.fr> References: <5012C559.4030300@univ-mlv.fr> Message-ID: Hi Remi How do I run with the backport? I am using OSX Lion. regards mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120727/c72185ac/attachment.html From forax at univ-mlv.fr Fri Jul 27 13:07:18 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 27 Jul 2012 22:07:18 +0200 Subject: Backport 2.0 RC In-Reply-To: References: <5012C559.4030300@univ-mlv.fr> Message-ID: <5012F4F6.4030704@univ-mlv.fr> On 07/27/2012 09:49 PM, Mark Roos wrote: > > Hi Remi > > How do I run with the backport? I am using OSX Lion. > > regards > mark > > download the backport, unzip the zip, in lib you have two files one is asm-4 and the other is the backport (jsr292-backport.jar) the jsr292-bkkcport.jar is a Java agent so you can just run with the jdk6 provided by Apple, java -javaagent:lib/jsr292-backport.jar YourMain the only constraint is that because jsr292-backport.jar has a dependency on asm.jar, they should be in the same directory. cheers, R?mi From mroos at roos.com Sun Jul 29 17:10:38 2012 From: mroos at roos.com (Mark Roos) Date: Sun, 29 Jul 2012 17:10:38 -0700 Subject: Backport 2.0 RC In-Reply-To: <5012F4F6.4030704@univ-mlv.fr> References: <5012C559.4030300@univ-mlv.fr> <5012F4F6.4030704@univ-mlv.fr> Message-ID: Hi R?mi gave it a shot with this launch java -javaagent:jsr292-backport.jar -agentpath:javaDebug.dylib ri/experiment2/TestSm Got this error C: Unable to locate callback class. java.lang.NoClassDefFoundError - klass: 'java/lang/NoClassDefFoundError' ./testBackport: line 3: 38777 Trace/BPT trap: 5 java -javaagent:jsr292-backport.jar -agentpath:javaDebug.dylib ri/experiment2/TestSm I usually put my jar file on the bootClassPath, but I didn't think I needed it here. everything is in the same directory see you tomorrow mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120729/0580df46/attachment.html From headius at headius.com Mon Jul 30 14:48:41 2012 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 30 Jul 2012 16:48:41 -0500 Subject: Backport 2.0 RC In-Reply-To: References: <5012C559.4030300@univ-mlv.fr> <5012F4F6.4030704@univ-mlv.fr> Message-ID: I tried it on JRuby...perhaps I'm doing something wrong: Command line: java -javaagent:lib/jsr292-backport.jar -Djruby.home=/Users/headius/projects/jruby -Djruby.compile.invokedynamic=true -Djruby.jit.logging.verbose=true -jar ../jruby/lib/jruby.jar -e "puts 1" Error: 2012-07-30T16:45:58.970-05:00: Ruby: java/lang/invoke/CallSite java.lang.NoClassDefFoundError: java/lang/invoke/CallSite at org.jruby.compiler.impl.InvokeDynamicCacheCompiler.cacheFixnum(InvokeDynamicCacheCompiler.java:231) at org.jruby.compiler.impl.BaseBodyCompiler.createNewFixnum(BaseBodyCompiler.java:429) at org.jruby.compiler.ASTCompiler.compileFixnum(ASTCompiler.java:2452) at org.jruby.compiler.ASTCompiler.compile(ASTCompiler.java:289) at org.jruby.compiler.ASTCompiler19.compile(ASTCompiler19.java:87) at org.jruby.compiler.ASTCompiler$SpecificArityArguments.call(ASTCompiler.java:523) - Charlie On Sun, Jul 29, 2012 at 7:10 PM, Mark Roos wrote: > Hi R?mi > > gave it a shot with this launch > java -javaagent:jsr292-backport.jar -agentpath:javaDebug.dylib > ri/experiment2/TestSm > > > Got this error > C: Unable to locate callback class. > java.lang.NoClassDefFoundError > - klass: 'java/lang/NoClassDefFoundError' > ./testBackport: line 3: 38777 Trace/BPT trap: 5 java > -javaagent:jsr292-backport.jar -agentpath:javaDebug.dylib > ri/experiment2/TestSm > > I usually put my jar file on the bootClassPath, but I didn't think I needed > it here. > > everything is in the same directory > > see you tomorrow > > mark > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From rkennke at redhat.com Tue Jul 31 05:19:14 2012 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 31 Jul 2012 14:19:14 +0200 Subject: Missing invokehandle handling in bytecodeInterpreter.cpp Message-ID: <1343737154.5485.3.camel@mercury> Hi there, I am currently (trying to) get the Hotspot-Zero port in shape for MLVM. I am running into a road block here: # Internal Error (/home/rkennke/src/openjdk/hotspot-comp/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:2464), pid=18585, tid=140737337317120 # fatal error: Unimplemented opcode 232 = invokehandle Looking at bytecodeInterpreter.cpp it seem to simply not handle invokehandle. I would like to add this, but I don't know what exactly this bytecode is supposed to do. Could you give me pointers to the necessary information or provide some help with this? (Or maybe I am doing something wrong here, and should not arrive there at all?) Regards, Roman From rkennke at redhat.com Tue Jul 31 08:24:59 2012 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 31 Jul 2012 17:24:59 +0200 Subject: Missing invokehandle handling in bytecodeInterpreter.cpp In-Reply-To: <1343737154.5485.3.camel@mercury> References: <1343737154.5485.3.camel@mercury> Message-ID: <1343748299.5485.30.camel@mercury> Am Dienstag, den 31.07.2012, 14:19 +0200 schrieb Roman Kennke: > Hi there, > > I am currently (trying to) get the Hotspot-Zero port in shape for MLVM. > I am running into a road block here: > > # Internal Error > (/home/rkennke/src/openjdk/hotspot-comp/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:2464), pid=18585, tid=140737337317120 > # fatal error: Unimplemented opcode 232 = invokehandle > > Looking at bytecodeInterpreter.cpp it seem to simply not handle > invokehandle. I would like to add this, but I don't know what exactly > this bytecode is supposed to do. Could you give me pointers to the > necessary information or provide some help with this? (Or maybe I am > doing something wrong here, and should not arrive there at all?) I disabled the invokevirtual->invokehandle rewriting for now (this should be safe/correct, right?), and it brings me further into my unimplemented handler for vmIntrinsics::_invokeBasic. Need to figure out what this is supposed to do (any hints about this one?).. Regards, Roman From christian.thalinger at oracle.com Tue Jul 31 17:28:32 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 31 Jul 2012 17:28:32 -0700 Subject: Missing invokehandle handling in bytecodeInterpreter.cpp In-Reply-To: <1343748299.5485.30.camel@mercury> References: <1343737154.5485.3.camel@mercury> <1343748299.5485.30.camel@mercury> Message-ID: <6B950D57-7ED1-4448-8707-FCEE32E6BB20@oracle.com> On Jul 31, 2012, at 8:24 AM, Roman Kennke wrote: > Am Dienstag, den 31.07.2012, 14:19 +0200 schrieb Roman Kennke: >> Hi there, >> >> I am currently (trying to) get the Hotspot-Zero port in shape for MLVM. >> I am running into a road block here: >> >> # Internal Error >> (/home/rkennke/src/openjdk/hotspot-comp/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:2464), pid=18585, tid=140737337317120 >> # fatal error: Unimplemented opcode 232 = invokehandle >> >> Looking at bytecodeInterpreter.cpp it seem to simply not handle >> invokehandle. I would like to add this, but I don't know what exactly >> this bytecode is supposed to do. Could you give me pointers to the >> necessary information or provide some help with this? (Or maybe I am >> doing something wrong here, and should not arrive there at all?) > > I disabled the invokevirtual->invokehandle rewriting for now (this > should be safe/correct, right?), and it brings me further into my > unimplemented handler for vmIntrinsics::_invokeBasic. Need to figure out > what this is supposed to do (any hints about this one?).. You can't disable the rewriting and run JSR 292 code. That simply won't work. Look at one of the implementations of TemplateTable::_invokehandle and try to do the same in the C++ interpreter. -- Chris > > Regards, > Roman > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From bobfoster at gmail.com Sat Jul 7 16:32:57 2012 From: bobfoster at gmail.com (Bob Foster) Date: Sat, 07 Jul 2012 23:32:57 -0000 Subject: [jvm-l] Improving the performance of stacktrace generation In-Reply-To: References: Message-ID: > Any thoughts on this? Does anyone else have need for lighter-weight name/file/line inspection of the call stack? Well, yes. Profilers do. Recall Cliff Click bragging a couple of years ago at the JVM Language Summit about how fast stack trace generation is in Azul Systems' OSs...and knocking Hotspot for being so slow. It turns out that stack trace generation is a very significant overhead in profiling Hotspot using JVMTI. Even CPU sampling on 20 ms. intervals can add 3% or more to execution time, almost entirely due to the delay in reaching a safe point (which also guarantees the profile will be incorrect) and generating a stack trace for each thread. But 3% is peanuts compared to the cost of memory profiling, which can require a stack trace on every new instance creation. In a profiler I wrote using JVMTI, I discovered that it was faster to call into JNI code on every method entry and exit (and exception catch), keeping a stack trace dynamically than to call into JNI only when memory was allocated and request a stack trace each time. The "fast" technique is about 3-10 times slower than running without profiling. The Netbeans profiler doesn't use this optimization, and its memory profiler when capturing every allocation, as I did, is 2-3 ORDERS OF MAGNITUDE slower than normal (non-server) execution. Faster stack traces would benefit the entire Hotspot profiling community. Bob On Sat, Jul 7, 2012 at 3:03 PM, Charles Oliver Nutter wrote: > Today I have a new conundrum for you all: I need stack trace > generation on Hotspot to be considerably faster than it is now. > > In order to simulate many Ruby features, JRuby (over)uses Java stack > traces. We recently (JRuby 1.6, about a year ago) moved to using the > Java stack trace as the source of our Ruby backtrace information, > mining out compiled frames and using interpreter markers to peel off > interpreter frames. The result is that a Ruby trace with mixed > compiled and interpreted code like this > (https://gist.github.com/3068210) turns into this > (https://gist.github.com/3068213). I consider this a great deal better > than the plain Java trace, and I know other language implementers have > lamented the verbosity of stack traces coming out of their languages. > > The unfortunate thing is that stack trace generation is very expensive > in the JVM, and in order to generate normal exceptions and emulate > other features we sometimes generate a lot of them. I think there's > value in exploring how we can make stack trace generation cheaper at > the JVM level. > > Here's a few cases in Ruby where we need to use Java stack traces to > provide the same features: > > * Exceptions as non-exceptional or moderately-exceptional method results > > In this case I'm specifically thinking about Ruby's tendency to > propagate errno values as exceptions; EAGAIN/EWOULDBLOCK for example > are thrown from nonblocking IO methods when there's no data available. > > You will probably say "that's a horrible use for exceptions" and I > agree. But there are a couple reasons why it's nicer too: > - using return value sigils requires you to propagate them back out > through many levels of calls > - exception-handling is cleaner in code than having all your errno > handling logic spliced into regular program flow > > In any case, the cost of generating a stack trace for potentially > every non-blocking IO call is obviously too high. In JRuby, we default > to having EAGAIN/EWOULDBLOCK exceptions not generate a stack trace, > and you must pass a flag for them to do so. The justification is that > these exceptions are almost always used to branch back to the top of a > nonblocking IO loop, so the backtrace is useless. > > * Getting the current or previous method's name/file/line > > Ruby supports a number of features that allow you to get basic > information about the method currently being executed or the method > that called it. The most general of these features is the "caller" > method, which provides an array of all method name + file + line that > would appear in a stack trace at this point. This feature is often > abused to get only the current or previous frame, and so in Ruby 1.9 > they added __method__ to get the currently-executing method's > name+file+line. > > In both cases, we must generate a full Java trace for these methods > because the name of a method body is not necessarily statically known. > We often want only the current frame or the current and previous > frames, but we pay the cost of generating an entire Java stack trace > to get them. > > * Warnings that actually report the line of code that triggered them > > In Ruby, it is possible to generate non-fatal warnings to stderr. In > many cases, these warnings automatically include the file and line at > which the triggering code lives. Because the warning logic is > downstream from the Ruby code, we again must use a full Java stack > trace to find the most recent (on stack) Ruby frame. This causes > warnings to be as expensive as regular exceptions. > > Because the use of frame introspection (in this case through stack > traces) has largely been ignored on current JVMs, I suspect there's a > lot of improvement possible. At a minimum, the ability to only grab > the top N frames from the stack trace could be a great improvement > (Hotspot even has flags to restrict how large a trace it will > generate, presumably to avoid the cost of accounting for deep stacks > and generating traces from them). > > Any thoughts on this? Does anyone else have need for lighter-weight > name/file/line inspection of the call stack? > > - Charlie > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to jvm-languages at googlegroups.com. > To unsubscribe from this group, send email to > jvm-languages+unsubscribe at googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120707/4369178a/attachment-0001.html From jzaugg at gmail.com Sun Jul 8 02:40:23 2012 From: jzaugg at gmail.com (Jason Zaugg) Date: Sun, 08 Jul 2012 09:40:23 -0000 Subject: Improving the performance of stacktrace generation In-Reply-To: References: Message-ID: On Sunday, July 8, 2012 12:03:34 AM UTC+2, Charles Oliver Nutter wrote: > > * Exceptions as non-exceptional or moderately-exceptional method results > > In this case I'm specifically thinking about Ruby's tendency to > propagate errno values as exceptions; EAGAIN/EWOULDBLOCK for example > are thrown from nonblocking IO methods when there's no data available. > > You will probably say "that's a horrible use for exceptions" and I > agree. But there are a couple reasons why it's nicer too: > - using return value sigils requires you to propagate them back out > through many levels of calls > - exception-handling is cleaner in code than having all your errno > handling logic spliced into regular program flow > > In any case, the cost of generating a stack trace for potentially > every non-blocking IO call is obviously too high. In JRuby, we default > to having EAGAIN/EWOULDBLOCK exceptions not generate a stack trace, > and you must pass a flag for them to do so. The justification is that > these exceptions are almost always used to branch back to the top of a > nonblocking IO loop, so the backtrace is useless. > That's also the approach used in Scala for non local returns from closures and breaks [1] [2]. -jason [1] https://github.com/scala/scala/blob/master/src/library/scala/util/control/NoStackTrace.scala [2] https://github.com/scala/scala/blob/master/src/library/scala/util/control/ControlThrowable.scala -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120708/03f40eeb/attachment-0001.html