From imdupeng at gmail.com Mon Mar 1 12:18:26 2010 From: imdupeng at gmail.com (Peng Du) Date: Mon, 01 Mar 2010 14:18:26 -0600 Subject: oop, Handle, and hash key Message-ID: <1267474706.16554.15.camel@witty-114b.unl.edu> Hello, I need unique and persistent identifiers to Java objects as keys to a hash table. However, I couldn't find an object_id kind routine. And I am not sure if identity_hash() guarantees uniqueness. So, I figured I can use the address of a Handle of an oop for this purpose, e.g. oop o; ... Handle h(o); ... hash.put(h->raw_value(), xx); Considering there is no HandleMark around the code, does this work? If yes, would GC reclaim the handle if the associated object (oop) dies? Thanks From imdupeng at gmail.com Mon Mar 1 13:09:05 2010 From: imdupeng at gmail.com (Peng Du) Date: Mon, 01 Mar 2010 15:09:05 -0600 Subject: oop, Handle, and hash key In-Reply-To: <4B8C2A5B.9050800@sun.com> References: <1267474706.16554.15.camel@witty-114b.unl.edu> <4B8C2A5B.9050800@sun.com> Message-ID: <1267477745.16554.21.camel@witty-114b.unl.edu> Hi, ramki Thanks for your quick reply! You're right about what I want. weak global JNI handle seems a good solution. I guess later I have to put some hooks into GC to do the reclamation. Otherwise, I need a periodic thread to do the housekeeping. In case I have further questions, I will post back. Thanks! On Mon, 2010-03-01 at 12:58 -0800, Y. Srinivas Ramakrishna wrote: > Hi Peng -- > > Peng Du wrote: > > Hello, > > > > I need unique and persistent identifiers to Java objects as keys to a > > hash table. However, I couldn't find an object_id kind routine. And I am > > not sure if identity_hash() guarantees uniqueness. So, I figured I can > > use the address of a Handle of an oop for this purpose, e.g. > > > > oop o; > > ... > > Handle h(o); > > ... > > hash.put(h->raw_value(), xx); > > > > > > Considering there is no HandleMark around the code, does this work? If > > yes, would GC reclaim the handle if the associated object (oop) dies? > > When would you release the handle? What you seem to need is > basically a weak global JNI handle. JVM internal Handle's will > not work in your case for the reasons you gave above -- you do > not have a HandleMark, so the lifetime of your handle is determined > by some unknown HandleMark in which your code is nesting above, and > so your handle will be destructed at some unspecified point depending > upon context. Worse, as long as your handle is in scope, the > object being referred to will be kept alive so you'll see > this as leaks in the java heap. I think (if i understood yr > use correctly) that what you really need is a weak global JNI ref > to use as the key into your hash table. And you'd need to periodically > remove the tombstone entries for the dead and reclaimed oop's (the > weak refs will not keep the oops alive which is exactly the > behaviour i think you want?). > > -- ramki > > > > > > > Thanks > > > > > > > From imdupeng at gmail.com Mon Mar 1 15:15:22 2010 From: imdupeng at gmail.com (Peng Du) Date: Mon, 01 Mar 2010 17:15:22 -0600 Subject: oop, Handle, and hash key In-Reply-To: <4B8C33ED.2090209@sun.com> References: <1267474706.16554.15.camel@witty-114b.unl.edu> <4B8C2A5B.9050800@sun.com> <1267477745.16554.21.camel@witty-114b.unl.edu> <4B8C33ED.2090209@sun.com> Message-ID: <1267485322.5865.16.camel@witty-114b.unl.edu> Ramki, First, I appreciate your quick follow-ups. Second, let me tell you what I want to do. Say I want to keep track of method calls of some Java objects during runtime. I have written some handlers, which will be invoked by the hooks in the interpreter. Now I need the reference to the receiver object of the method as a key to the hash table to store some state information. Given the volatile nature of the oops, I have to use something else as the hash key. Then came the idea of Handle. I just read the code of JNIHandles::make_global(), which always allocate fresh handles upon requested. So, I guess you are right in the 2nd post. I can use it to identify the objects. Given the scenario, what do you think is the best solution? Thank you again! On Mon, 2010-03-01 at 13:38 -0800, Y. Srinivas Ramakrishna wrote: > On further thought this may or may not work for you > because of "aliasing"... The same oop o may have more > than one JNI weak reference to it (just as might have > been the case for your Handle idea below). So while > JNI weak refs will have the property that > no two oops will have the same key, it is possible that > the same oop may be referred to by several distinct > handles and thus the key is not a canonical identifier > for an oop either. > > So i guess it really depends on how you were going to > use your hashtable, and JNI weak refs may not work either. > > Sorry for the hasty earlier response. > -- ramki > > Peng Du wrote: > > Hi, ramki > > > > Thanks for your quick reply! You're right about what I want. weak global > > JNI handle seems a good solution. I guess later I have to put some hooks > > into GC to do the reclamation. Otherwise, I need a periodic thread to do > > the housekeeping. > > > > In case I have further questions, I will post back. Thanks! > > > > > > On Mon, 2010-03-01 at 12:58 -0800, Y. Srinivas Ramakrishna wrote: > >> Hi Peng -- > >> > >> Peng Du wrote: > >>> Hello, > >>> > >>> I need unique and persistent identifiers to Java objects as keys to a > >>> hash table. However, I couldn't find an object_id kind routine. And I am > >>> not sure if identity_hash() guarantees uniqueness. So, I figured I can > >>> use the address of a Handle of an oop for this purpose, e.g. > >>> > >>> oop o; > >>> ... > >>> Handle h(o); > >>> ... > >>> hash.put(h->raw_value(), xx); > >>> > >>> > >>> Considering there is no HandleMark around the code, does this work? If > >>> yes, would GC reclaim the handle if the associated object (oop) dies? > >> When would you release the handle? What you seem to need is > >> basically a weak global JNI handle. JVM internal Handle's will > >> not work in your case for the reasons you gave above -- you do > >> not have a HandleMark, so the lifetime of your handle is determined > >> by some unknown HandleMark in which your code is nesting above, and > >> so your handle will be destructed at some unspecified point depending > >> upon context. Worse, as long as your handle is in scope, the > >> object being referred to will be kept alive so you'll see > >> this as leaks in the java heap. I think (if i understood yr > >> use correctly) that what you really need is a weak global JNI ref > >> to use as the key into your hash table. And you'd need to periodically > >> remove the tombstone entries for the dead and reclaimed oop's (the > >> weak refs will not keep the oops alive which is exactly the > >> behaviour i think you want?). > >> > >> -- ramki > >> > >>> > >>> Thanks > >>> > >>> > >>> > > > > > From Thomas.Rodriguez at Sun.COM Mon Mar 1 15:38:15 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 01 Mar 2010 15:38:15 -0800 Subject: oop, Handle, and hash key In-Reply-To: <1267485322.5865.16.camel@witty-114b.unl.edu> References: <1267474706.16554.15.camel@witty-114b.unl.edu> <4B8C2A5B.9050800@sun.com> <1267477745.16554.21.camel@witty-114b.unl.edu> <4B8C33ED.2090209@sun.com> <1267485322.5865.16.camel@witty-114b.unl.edu> Message-ID: <925DE5BE-1096-4D85-8025-3192BCCFB983@sun.com> You can't use the address of any kind of handle for your hash since there's no way to reverse that mapping. You can always allocate a handle of some kind for an arbitrary object but you can't look up a unique handle from the oop without having some other key to hash on. You could use identity hash code since that is persistent but I'm not sure I would use that with perm objects since they aren't really Java objects. If you are tracking methodOops only then you can build hash key from the method name, klass and signature since those are stable or you might able to be able to use the jmethodID which is a system managed unique weak global reference to the methodOops. jmethodID is just a type alias for jobject so it's a pointer and you could use that as your hash. tom On Mar 1, 2010, at 3:15 PM, Peng Du wrote: > Ramki, > > First, I appreciate your quick follow-ups. Second, let me tell you what > I want to do. Say I want to keep track of method calls of some Java > objects during runtime. I have written some handlers, which will be > invoked by the hooks in the interpreter. Now I need the reference to the > receiver object of the method as a key to the hash table to store some > state information. Given the volatile nature of the oops, I have to use > something else as the hash key. Then came the idea of Handle. > > I just read the code of JNIHandles::make_global(), which always allocate > fresh handles upon requested. So, I guess you are right in the 2nd post. > I can use it to identify the objects. > > Given the scenario, what do you think is the best solution? > > Thank you again! > > > > > > On Mon, 2010-03-01 at 13:38 -0800, Y. Srinivas Ramakrishna wrote: >> On further thought this may or may not work for you >> because of "aliasing"... The same oop o may have more >> than one JNI weak reference to it (just as might have >> been the case for your Handle idea below). So while >> JNI weak refs will have the property that >> no two oops will have the same key, it is possible that >> the same oop may be referred to by several distinct >> handles and thus the key is not a canonical identifier >> for an oop either. >> >> So i guess it really depends on how you were going to >> use your hashtable, and JNI weak refs may not work either. >> >> Sorry for the hasty earlier response. >> -- ramki >> >> Peng Du wrote: >>> Hi, ramki >>> >>> Thanks for your quick reply! You're right about what I want. weak global >>> JNI handle seems a good solution. I guess later I have to put some hooks >>> into GC to do the reclamation. Otherwise, I need a periodic thread to do >>> the housekeeping. >>> >>> In case I have further questions, I will post back. Thanks! >>> >>> >>> On Mon, 2010-03-01 at 12:58 -0800, Y. Srinivas Ramakrishna wrote: >>>> Hi Peng -- >>>> >>>> Peng Du wrote: >>>>> Hello, >>>>> >>>>> I need unique and persistent identifiers to Java objects as keys to a >>>>> hash table. However, I couldn't find an object_id kind routine. And I am >>>>> not sure if identity_hash() guarantees uniqueness. So, I figured I can >>>>> use the address of a Handle of an oop for this purpose, e.g. >>>>> >>>>> oop o; >>>>> ... >>>>> Handle h(o); >>>>> ... >>>>> hash.put(h->raw_value(), xx); >>>>> >>>>> >>>>> Considering there is no HandleMark around the code, does this work? If >>>>> yes, would GC reclaim the handle if the associated object (oop) dies? >>>> When would you release the handle? What you seem to need is >>>> basically a weak global JNI handle. JVM internal Handle's will >>>> not work in your case for the reasons you gave above -- you do >>>> not have a HandleMark, so the lifetime of your handle is determined >>>> by some unknown HandleMark in which your code is nesting above, and >>>> so your handle will be destructed at some unspecified point depending >>>> upon context. Worse, as long as your handle is in scope, the >>>> object being referred to will be kept alive so you'll see >>>> this as leaks in the java heap. I think (if i understood yr >>>> use correctly) that what you really need is a weak global JNI ref >>>> to use as the key into your hash table. And you'd need to periodically >>>> remove the tombstone entries for the dead and reclaimed oop's (the >>>> weak refs will not keep the oops alive which is exactly the >>>> behaviour i think you want?). >>>> >>>> -- ramki >>>> >>>>> >>>>> Thanks >>>>> >>>>> >>>>> >>> >>> >> > > From imdupeng at gmail.com Mon Mar 1 15:50:24 2010 From: imdupeng at gmail.com (Peng Du) Date: Mon, 01 Mar 2010 17:50:24 -0600 Subject: oop, Handle, and hash key In-Reply-To: <925DE5BE-1096-4D85-8025-3192BCCFB983@sun.com> References: <1267474706.16554.15.camel@witty-114b.unl.edu> <4B8C2A5B.9050800@sun.com> <1267477745.16554.21.camel@witty-114b.unl.edu> <4B8C33ED.2090209@sun.com> <1267485322.5865.16.camel@witty-114b.unl.edu> <925DE5BE-1096-4D85-8025-3192BCCFB983@sun.com> Message-ID: <1267487424.5865.20.camel@witty-114b.unl.edu> Thanks, Tom Unfortunately, I need to track the method invocation per object basis. For example, if method hello() in class Foo is called, I need to know which receiver (instance) it is called on. Then I can relate the call to the value I kept in my hash table. So, I really need an persistent ID to the object, not the method. Any idea how that can be done? Thanks On Mon, 2010-03-01 at 15:38 -0800, Tom Rodriguez wrote: > You can't use the address of any kind of handle for your hash since there's no way to reverse that mapping. You can always allocate a handle of some kind for an arbitrary object but you can't look up a unique handle from the oop without having some other key to hash on. You could use identity hash code since that is persistent but I'm not sure I would use that with perm objects since they aren't really Java objects. If you are tracking methodOops only then you can build hash key from the method name, klass and signature since those are stable or you might able to be able to use the jmethodID which is a system managed unique weak global reference to the methodOops. jmethodID is just a type alias for jobject so it's a pointer and you could use that as your hash. > > tom > > On Mar 1, 2010, at 3:15 PM, Peng Du wrote: > > > Ramki, > > > > First, I appreciate your quick follow-ups. Second, let me tell you what > > I want to do. Say I want to keep track of method calls of some Java > > objects during runtime. I have written some handlers, which will be > > invoked by the hooks in the interpreter. Now I need the reference to the > > receiver object of the method as a key to the hash table to store some > > state information. Given the volatile nature of the oops, I have to use > > something else as the hash key. Then came the idea of Handle. > > > > I just read the code of JNIHandles::make_global(), which always allocate > > fresh handles upon requested. So, I guess you are right in the 2nd post. > > I can use it to identify the objects. > > > > Given the scenario, what do you think is the best solution? > > > > Thank you again! > > > > > > > > > > > > On Mon, 2010-03-01 at 13:38 -0800, Y. Srinivas Ramakrishna wrote: > >> On further thought this may or may not work for you > >> because of "aliasing"... The same oop o may have more > >> than one JNI weak reference to it (just as might have > >> been the case for your Handle idea below). So while > >> JNI weak refs will have the property that > >> no two oops will have the same key, it is possible that > >> the same oop may be referred to by several distinct > >> handles and thus the key is not a canonical identifier > >> for an oop either. > >> > >> So i guess it really depends on how you were going to > >> use your hashtable, and JNI weak refs may not work either. > >> > >> Sorry for the hasty earlier response. > >> -- ramki > >> > >> Peng Du wrote: > >>> Hi, ramki > >>> > >>> Thanks for your quick reply! You're right about what I want. weak global > >>> JNI handle seems a good solution. I guess later I have to put some hooks > >>> into GC to do the reclamation. Otherwise, I need a periodic thread to do > >>> the housekeeping. > >>> > >>> In case I have further questions, I will post back. Thanks! > >>> > >>> > >>> On Mon, 2010-03-01 at 12:58 -0800, Y. Srinivas Ramakrishna wrote: > >>>> Hi Peng -- > >>>> > >>>> Peng Du wrote: > >>>>> Hello, > >>>>> > >>>>> I need unique and persistent identifiers to Java objects as keys to a > >>>>> hash table. However, I couldn't find an object_id kind routine. And I am > >>>>> not sure if identity_hash() guarantees uniqueness. So, I figured I can > >>>>> use the address of a Handle of an oop for this purpose, e.g. > >>>>> > >>>>> oop o; > >>>>> ... > >>>>> Handle h(o); > >>>>> ... > >>>>> hash.put(h->raw_value(), xx); > >>>>> > >>>>> > >>>>> Considering there is no HandleMark around the code, does this work? If > >>>>> yes, would GC reclaim the handle if the associated object (oop) dies? > >>>> When would you release the handle? What you seem to need is > >>>> basically a weak global JNI handle. JVM internal Handle's will > >>>> not work in your case for the reasons you gave above -- you do > >>>> not have a HandleMark, so the lifetime of your handle is determined > >>>> by some unknown HandleMark in which your code is nesting above, and > >>>> so your handle will be destructed at some unspecified point depending > >>>> upon context. Worse, as long as your handle is in scope, the > >>>> object being referred to will be kept alive so you'll see > >>>> this as leaks in the java heap. I think (if i understood yr > >>>> use correctly) that what you really need is a weak global JNI ref > >>>> to use as the key into your hash table. And you'd need to periodically > >>>> remove the tombstone entries for the dead and reclaimed oop's (the > >>>> weak refs will not keep the oops alive which is exactly the > >>>> behaviour i think you want?). > >>>> > >>>> -- ramki > >>>> > >>>>> > >>>>> Thanks > >>>>> > >>>>> > >>>>> > >>> > >>> > >> > > > > > From Thomas.Rodriguez at Sun.COM Mon Mar 1 16:02:18 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 01 Mar 2010 16:02:18 -0800 Subject: oop, Handle, and hash key In-Reply-To: <1267487424.5865.20.camel@witty-114b.unl.edu> References: <1267474706.16554.15.camel@witty-114b.unl.edu> <4B8C2A5B.9050800@sun.com> <1267477745.16554.21.camel@witty-114b.unl.edu> <4B8C33ED.2090209@sun.com> <1267485322.5865.16.camel@witty-114b.unl.edu> <925DE5BE-1096-4D85-8025-3192BCCFB983@sun.com> <1267487424.5865.20.camel@witty-114b.unl.edu> Message-ID: <6EC1AED3-D497-4E06-A289-D7C097196588@Sun.COM> Identity hash code is the only obvious way to me. That's going to be a big hash table. JVMTI provides a tagging facility, SetTag/GetTag, that does something like what you want. tom On Mar 1, 2010, at 3:50 PM, Peng Du wrote: > Thanks, Tom > > Unfortunately, I need to track the method invocation per object basis. > For example, if method hello() in class Foo is called, I need to know > which receiver (instance) it is called on. Then I can relate the call to > the value I kept in my hash table. So, I really need an persistent ID to > the object, not the method. > > Any idea how that can be done? > > Thanks > > > On Mon, 2010-03-01 at 15:38 -0800, Tom Rodriguez wrote: >> You can't use the address of any kind of handle for your hash since there's no way to reverse that mapping. You can always allocate a handle of some kind for an arbitrary object but you can't look up a unique handle from the oop without having some other key to hash on. You could use identity hash code since that is persistent but I'm not sure I would use that with perm objects since they aren't really Java objects. If you are tracking methodOops only then you can build hash key from the method name, klass and signature since those are stable or you might able to be able to use the jmethodID which is a system managed unique weak global reference to the methodOops. jmethodID is just a type alias for jobject so it's a pointer and you could use that as your hash. >> >> tom >> >> On Mar 1, 2010, at 3:15 PM, Peng Du wrote: >> >>> Ramki, >>> >>> First, I appreciate your quick follow-ups. Second, let me tell you what >>> I want to do. Say I want to keep track of method calls of some Java >>> objects during runtime. I have written some handlers, which will be >>> invoked by the hooks in the interpreter. Now I need the reference to the >>> receiver object of the method as a key to the hash table to store some >>> state information. Given the volatile nature of the oops, I have to use >>> something else as the hash key. Then came the idea of Handle. >>> >>> I just read the code of JNIHandles::make_global(), which always allocate >>> fresh handles upon requested. So, I guess you are right in the 2nd post. >>> I can use it to identify the objects. >>> >>> Given the scenario, what do you think is the best solution? >>> >>> Thank you again! >>> >>> >>> >>> >>> >>> On Mon, 2010-03-01 at 13:38 -0800, Y. Srinivas Ramakrishna wrote: >>>> On further thought this may or may not work for you >>>> because of "aliasing"... The same oop o may have more >>>> than one JNI weak reference to it (just as might have >>>> been the case for your Handle idea below). So while >>>> JNI weak refs will have the property that >>>> no two oops will have the same key, it is possible that >>>> the same oop may be referred to by several distinct >>>> handles and thus the key is not a canonical identifier >>>> for an oop either. >>>> >>>> So i guess it really depends on how you were going to >>>> use your hashtable, and JNI weak refs may not work either. >>>> >>>> Sorry for the hasty earlier response. >>>> -- ramki >>>> >>>> Peng Du wrote: >>>>> Hi, ramki >>>>> >>>>> Thanks for your quick reply! You're right about what I want. weak global >>>>> JNI handle seems a good solution. I guess later I have to put some hooks >>>>> into GC to do the reclamation. Otherwise, I need a periodic thread to do >>>>> the housekeeping. >>>>> >>>>> In case I have further questions, I will post back. Thanks! >>>>> >>>>> >>>>> On Mon, 2010-03-01 at 12:58 -0800, Y. Srinivas Ramakrishna wrote: >>>>>> Hi Peng -- >>>>>> >>>>>> Peng Du wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I need unique and persistent identifiers to Java objects as keys to a >>>>>>> hash table. However, I couldn't find an object_id kind routine. And I am >>>>>>> not sure if identity_hash() guarantees uniqueness. So, I figured I can >>>>>>> use the address of a Handle of an oop for this purpose, e.g. >>>>>>> >>>>>>> oop o; >>>>>>> ... >>>>>>> Handle h(o); >>>>>>> ... >>>>>>> hash.put(h->raw_value(), xx); >>>>>>> >>>>>>> >>>>>>> Considering there is no HandleMark around the code, does this work? If >>>>>>> yes, would GC reclaim the handle if the associated object (oop) dies? >>>>>> When would you release the handle? What you seem to need is >>>>>> basically a weak global JNI handle. JVM internal Handle's will >>>>>> not work in your case for the reasons you gave above -- you do >>>>>> not have a HandleMark, so the lifetime of your handle is determined >>>>>> by some unknown HandleMark in which your code is nesting above, and >>>>>> so your handle will be destructed at some unspecified point depending >>>>>> upon context. Worse, as long as your handle is in scope, the >>>>>> object being referred to will be kept alive so you'll see >>>>>> this as leaks in the java heap. I think (if i understood yr >>>>>> use correctly) that what you really need is a weak global JNI ref >>>>>> to use as the key into your hash table. And you'd need to periodically >>>>>> remove the tombstone entries for the dead and reclaimed oop's (the >>>>>> weak refs will not keep the oops alive which is exactly the >>>>>> behaviour i think you want?). >>>>>> >>>>>> -- ramki >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From imdupeng at gmail.com Mon Mar 1 16:13:05 2010 From: imdupeng at gmail.com (Peng Du) Date: Mon, 1 Mar 2010 18:13:05 -0600 Subject: oop, Handle, and hash key In-Reply-To: <4B8C55EA.8040807@sun.com> References: <1267474706.16554.15.camel@witty-114b.unl.edu> <4B8C2A5B.9050800@sun.com> <1267477745.16554.21.camel@witty-114b.unl.edu> <4B8C33ED.2090209@sun.com> <1267485322.5865.16.camel@witty-114b.unl.edu> <925DE5BE-1096-4D85-8025-3192BCCFB983@sun.com> <1267487424.5865.20.camel@witty-114b.unl.edu> <4B8C55EA.8040807@sun.com> Message-ID: Tom and Ramki, Thanks for the pointers, according to which there is not easy way for such things. I guess have to to revise my design and come up with new protocols. Otherwise, I will try Ramki's solution. I might follow up when I meet further problems. Thanks, guys. On Mon, Mar 1, 2010 at 6:03 PM, Y. Srinivas Ramakrishna < Y.S.Ramakrishna at sun.com> wrote: > Peng Du wrote: > >> Thanks, Tom >> >> Unfortunately, I need to track the method invocation per object basis. >> For example, if method hello() in class Foo is called, I need to know >> which receiver (instance) it is called on. Then I can relate the call to >> the value I kept in my hash table. So, I really need an persistent ID to >> the object, not the method. >> Any idea how that can be done? >> > > Use the identity hash as a key and maintain a weak ref to the object along > with yr state > information for that entry. The weak ref will be updated by GC when an > object moves and > cleared when the object dies and is reclaimed by GC. Then use the identity > hashcode to > access yr object and use the object address to compare against the weak ref > value in the > table to locate the corresponding entry. This is somewhat cumbersome but > should work. I think. > > -- ramki > > > >> Thanks >> >> On Mon, 2010-03-01 at 15:38 -0800, Tom Rodriguez wrote: >> >>> You can't use the address of any kind of handle for your hash since >>> there's no way to reverse that mapping. You can always allocate a handle of >>> some kind for an arbitrary object but you can't look up a unique handle from >>> the oop without having some other key to hash on. You could use identity >>> hash code since that is persistent but I'm not sure I would use that with >>> perm objects since they aren't really Java objects. If you are tracking >>> methodOops only then you can build hash key from the method name, klass and >>> signature since those are stable or you might able to be able to use the >>> jmethodID which is a system managed unique weak global reference to the >>> methodOops. jmethodID is just a type alias for jobject so it's a pointer >>> and you could use that as your hash. >>> >>> tom >>> >>> On Mar 1, 2010, at 3:15 PM, Peng Du wrote: >>> >>> Ramki, >>>> First, I appreciate your quick follow-ups. Second, let me tell you what >>>> I want to do. Say I want to keep track of method calls of some Java >>>> objects during runtime. I have written some handlers, which will be >>>> invoked by the hooks in the interpreter. Now I need the reference to the >>>> receiver object of the method as a key to the hash table to store some >>>> state information. Given the volatile nature of the oops, I have to use >>>> something else as the hash key. Then came the idea of Handle. >>>> I just read the code of JNIHandles::make_global(), which always allocate >>>> fresh handles upon requested. So, I guess you are right in the 2nd post. >>>> I can use it to identify the objects. >>>> Given the scenario, what do you think is the best solution? >>>> Thank you again! >>>> >>>> >>>> >>>> >>>> >>>> On Mon, 2010-03-01 at 13:38 -0800, Y. Srinivas Ramakrishna wrote: >>>> >>>>> On further thought this may or may not work for you >>>>> because of "aliasing"... The same oop o may have more >>>>> than one JNI weak reference to it (just as might have >>>>> been the case for your Handle idea below). So while >>>>> JNI weak refs will have the property that >>>>> no two oops will have the same key, it is possible that >>>>> the same oop may be referred to by several distinct >>>>> handles and thus the key is not a canonical identifier >>>>> for an oop either. >>>>> >>>>> So i guess it really depends on how you were going to >>>>> use your hashtable, and JNI weak refs may not work either. >>>>> >>>>> Sorry for the hasty earlier response. >>>>> -- ramki >>>>> >>>>> Peng Du wrote: >>>>> >>>>>> Hi, ramki >>>>>> >>>>>> Thanks for your quick reply! You're right about what I want. weak >>>>>> global >>>>>> JNI handle seems a good solution. I guess later I have to put some >>>>>> hooks >>>>>> into GC to do the reclamation. Otherwise, I need a periodic thread to >>>>>> do >>>>>> the housekeeping. >>>>>> In case I have further questions, I will post back. Thanks! >>>>>> >>>>>> >>>>>> On Mon, 2010-03-01 at 12:58 -0800, Y. Srinivas Ramakrishna wrote: >>>>>> >>>>>>> Hi Peng -- >>>>>>> >>>>>>> Peng Du wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> I need unique and persistent identifiers to Java objects as keys to >>>>>>>> a >>>>>>>> hash table. However, I couldn't find an object_id kind routine. And >>>>>>>> I am >>>>>>>> not sure if identity_hash() guarantees uniqueness. So, I figured I >>>>>>>> can >>>>>>>> use the address of a Handle of an oop for this purpose, e.g. >>>>>>>> oop o; >>>>>>>> ... >>>>>>>> Handle h(o); >>>>>>>> ... >>>>>>>> hash.put(h->raw_value(), xx); >>>>>>>> >>>>>>>> >>>>>>>> Considering there is no HandleMark around the code, does this work? >>>>>>>> If >>>>>>>> yes, would GC reclaim the handle if the associated object (oop) >>>>>>>> dies? >>>>>>>> >>>>>>> When would you release the handle? What you seem to need is >>>>>>> basically a weak global JNI handle. JVM internal Handle's will >>>>>>> not work in your case for the reasons you gave above -- you do >>>>>>> not have a HandleMark, so the lifetime of your handle is determined >>>>>>> by some unknown HandleMark in which your code is nesting above, and >>>>>>> so your handle will be destructed at some unspecified point depending >>>>>>> upon context. Worse, as long as your handle is in scope, the >>>>>>> object being referred to will be kept alive so you'll see >>>>>>> this as leaks in the java heap. I think (if i understood yr >>>>>>> use correctly) that what you really need is a weak global JNI ref >>>>>>> to use as the key into your hash table. And you'd need to >>>>>>> periodically >>>>>>> remove the tombstone entries for the dead and reclaimed oop's (the >>>>>>> weak refs will not keep the oops alive which is exactly the >>>>>>> behaviour i think you want?). >>>>>>> >>>>>>> -- ramki >>>>>>> >>>>>>> Thanks >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100301/693f4210/attachment.html From Ulf.Zibis at gmx.de Tue Mar 2 01:48:33 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 02 Mar 2010 10:48:33 +0100 Subject: oop, Handle, and hash key In-Reply-To: <1267474706.16554.15.camel@witty-114b.unl.edu> References: <1267474706.16554.15.camel@witty-114b.unl.edu> Message-ID: <4B8CDEF1.2050500@gmx.de> Maybe you can take a look at db4o . They track an ID to each object. -Ulf Am 01.03.2010 21:18, schrieb Peng Du: > Hello, > > I need unique and persistent identifiers to Java objects as keys to a > hash table. However, I couldn't find an object_id kind routine. And I am > not sure if identity_hash() guarantees uniqueness. So, I figured I can > use the address of a Handle of an oop for this purpose, e.g. > > oop o; > ... > Handle h(o); > ... > hash.put(h->raw_value(), xx); > > > Considering there is no HandleMark around the code, does this work? If > yes, would GC reclaim the handle if the associated object (oop) dies? > > > Thanks > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100302/29183491/attachment.html From imdupeng at gmail.com Tue Mar 2 09:35:37 2010 From: imdupeng at gmail.com (Peng Du) Date: Tue, 02 Mar 2010 11:35:37 -0600 Subject: oop, Handle, and hash key In-Reply-To: <4B8CDEF1.2050500@gmx.de> References: <1267474706.16554.15.camel@witty-114b.unl.edu> <4B8CDEF1.2050500@gmx.de> Message-ID: <1267551337.14941.1.camel@witty-114b.unl.edu> Hi, Ulf Thanks for bring up db4o. I am not familiar with db4o. But it seems to me a Java application instead of VM. Anyway, I use the identity_hash() for my idea and it works pretty well. Thanks, guys. On Tue, 2010-03-02 at 10:48 +0100, Ulf Zibis wrote: > Maybe you can take a look at db4o. > They track an ID to each object. > > -Ulf > > > Am 01.03.2010 21:18, schrieb Peng Du: > > Hello, > > > > I need unique and persistent identifiers to Java objects as keys to a > > hash table. However, I couldn't find an object_id kind routine. And I am > > not sure if identity_hash() guarantees uniqueness. So, I figured I can > > use the address of a Handle of an oop for this purpose, e.g. > > > > oop o; > > ... > > Handle h(o); > > ... > > hash.put(h->raw_value(), xx); > > > > > > Considering there is no HandleMark around the code, does this work? If > > yes, would GC reclaim the handle if the associated object (oop) dies? > > > > > > Thanks > > > > > > > > > > From Christian.Thalinger at Sun.COM Tue Mar 2 11:44:32 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 02 Mar 2010 19:44:32 +0000 Subject: hg: jdk7/hotspot/hotspot: 9 new changesets Message-ID: <20100302194459.91A4A41F62@hg.openjdk.java.net> Changeset: 877a14af58e1 Author: never Date: 2010-02-18 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/877a14af58e1 6663854: assert(n != __null,"Bad immediate dominator info.") in C2 with -Xcomp Reviewed-by: kvn ! src/share/vm/opto/split_if.cpp + test/compiler/6663854/Test6663854.java Changeset: 2883969d09e7 Author: kvn Date: 2010-02-19 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2883969d09e7 6910664: C2: java/util/Arrays/Sorting.java fails with DeoptimizeALot flag Summary: Matcher::float_in_double should be true only when FPU is used for floats. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/output.cpp Changeset: b71f13525cc8 Author: never Date: 2010-02-19 13:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b71f13525cc8 6927049: assert(is_Loop(),"invalid node class") Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: 8b38237bae55 Author: kvn Date: 2010-02-22 16:56 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8b38237bae55 6928717: HS17 fails to build with SS11 C++ Summary: Add missing handles.inline.hpp for codeCache.cpp. Reviewed-by: never ! src/share/vm/includeDB_core Changeset: 855c5171834c Author: twisti Date: 2010-02-23 17:46 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/855c5171834c 6928839: JSR 292 typo in x86 _adapter_check_cast Summary: There is a small typo in methodHandles_x86.cpp. Reviewed-by: kvn ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: da9559b49b84 Author: never Date: 2010-02-25 11:38 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/da9559b49b84 6915557: assert(_gvn.type(l)->higher_equal(type),"must constrain OSR typestate") with debug build Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp Changeset: 2432acbee618 Author: kvn Date: 2010-02-25 15:55 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2432acbee618 6930035: C2 type system incorrectly handles case j.l.Object->meet(constant AryPtr) Summary: Add missing code. Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: 336c6c200f5f Author: kvn Date: 2010-02-25 22:58 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/336c6c200f5f 6930116: loop predication code does not handle If nodes with only one projection Summary: Add check for iff->outcnt() < 2. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: 7d236a9688c5 Author: never Date: 2010-03-01 12:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7d236a9688c5 6930398: fix for return address locals in OSR entries uses wrong test Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp From john.cuthbertson at sun.com Tue Mar 2 16:38:33 2010 From: john.cuthbertson at sun.com (john.cuthbertson at sun.com) Date: Wed, 03 Mar 2010 00:38:33 +0000 Subject: hg: jdk7/hotspot/hotspot: 7 new changesets Message-ID: <20100303003854.BDECF41FB3@hg.openjdk.java.net> Changeset: b81f3572f355 Author: tonyp Date: 2010-02-23 23:13 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b81f3572f355 6928059: G1: command line parameter renaming Summary: Rename G1 parameters to make them more consistent. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 1c72304f1885 Author: tonyp Date: 2010-02-23 23:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1c72304f1885 6928073: G1: use existing command line parameters for marking cycle initiation Summary: replace the combination of the G1SteadyStateUsed / G1SteadyStateUsedDelta parameteres to decide the marking initiation threshold and instead use InitiatingHeapOccupancyPercent. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5f1f51edaff6 Author: jmasa Date: 2010-02-24 07:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5f1f51edaff6 6928081: G1: rename parameters common with CMS Summary: Rename marking stack sizing flags to be common between G1 and CMS Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: a1c410de27e4 Author: tonyp Date: 2010-02-24 14:56 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a1c410de27e4 6928065: G1: use existing command line parameters to set the young generation size Summary: see synopsis Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ab75c83d7c37 Author: johnc Date: 2010-03-02 13:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ab75c83d7c37 Merge ! src/share/vm/includeDB_core Changeset: 8911d8c0596f Author: phh Date: 2010-02-26 16:40 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8911d8c0596f 6923123: Hotspot refuses to start when -Xmx4m or -Xms4m is specified Summary: Reduce NewSize from 4m to 1m. Reviewed-by: tonyp, jmasa ! src/share/vm/runtime/globals.hpp Changeset: c76ca382971b Author: johnc Date: 2010-03-02 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c76ca382971b Merge ! src/share/vm/runtime/globals.hpp From imdupeng at gmail.com Tue Mar 2 21:24:55 2010 From: imdupeng at gmail.com (Peng Du) Date: Tue, 2 Mar 2010 23:24:55 -0600 Subject: Question on TemplateTable::prepare_invoke Message-ID: Hello, I have a very specific question about an error I ran into today. I am very familiar with assembly programming. So, please bear with me. If I understand correctly, TemplateTable::prepare_invoke is a helper methods for the invokeXXX bytecodes. What I tried to do was to pass the oop of the method receiver to InterpreterRuntime::cache_object, which simply caches it in the current thread. Below is an excerpt in templateTable_x86_64.cpp) that I modified, the cache_object method in interpreterRuntime.cpp, and the cache_object method in thread.hpp: =========================================================== void TemplateTable::prepare_invoke(Register, Register, int) { const Register recv = rcx; ... // load receiver if needed (note: no return address pushed yet) if (load_receiver) { __ movl(recv, flags); __ andl(recv, 0xFF); if (TaggedStackInterpreter) __ shll(recv, 1); // index*2 Address recv_addr(rsp, recv, Address::times_8, -Interpreter::expr_offset_in_bytes(1)); if (is_invokedynamic) { __ lea(recv, recv_addr); } else { __ movptr(recv, recv_addr); __ verify_oop(recv); } // !!! cache receiver object !!! __ call_VM(noreg, CAST_FROM_FN_PTR(address, InterpreterRuntime::cache_object), recv); } ... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IRT_ENTRY(void, InterpreterRuntime::cache_object(JavaThread* thread, oop o)) thread->cache_object(o); IRT_END ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ class JavaThread { ... inline void cache_object(oop o) { _object = o; } =========================================================== However, this failed even in test_gamma with the following error: Error occurred during initialization of VM java.lang.StackOverflowError at java.lang.NullPointerException.(NullPointerException.java:53) at java.lang.NullPointerException.(NullPointerException.java:53) < a long list of NullPointerException same as above ... > at java.lang.String.(String.java:1218) It appeared to me there is infinite recursive creations of NullPointerException somewhere caused by the static initializer in String class. String.java:1218 looks like this: public static final Comparator CASE_INSENSITIVE_ORDER = new CaseInsensitiveComparator(); Is it because I somehow clobber the recv (rcx) register? Or can someone tell me what I did was wrong and how to fix it? Moreover, is there any documentation on the rules that how registers are used in template interpreter? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100302/9cef9f3b/attachment.html From aph at redhat.com Wed Mar 3 07:18:26 2010 From: aph at redhat.com (Andrew Haley) Date: Wed, 03 Mar 2010 15:18:26 +0000 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <401A9C44-0A14-49AB-A771-A049BC04AE12@Sun.COM> References: <4B1FC407.6010405@redhat.com> <4B477E05.5050207@redhat.com> <4B486278.9040005@redhat.com> <448B68EA-1FE2-430C-A534-A8598652C046@Sun.COM> <4B55D97D.4020001@redhat.com> <5D1BE1E0-B1D9-465F-A29F-A46802BD7F43@Sun.COM> <4B56D7E0.6020702@redhat.com> <401A9C44-0A14-49AB-A771-A049BC04AE12@Sun.COM> Message-ID: <4B8E7DC2.2010905@redhat.com> On 01/20/2010 05:35 PM, Tom Rodriguez wrote: > > On Jan 20, 2010, at 2:16 AM, Andrew Haley wrote: > >> On 01/19/2010 07:43 PM, Tom Rodriguez wrote: >> >>> So do you want to pursue making the SA work with a stripped >>> libjvm.so or is requiring debug info to be installed acceptable? >>> Sorry if I made this more complicated than you wanted. I think your >>> original change is fine, but if the norm is being stripped then >>> making these tools work in that situation would be good. >> >> Clearly it would be. Java programmers on Linux systems aren't used to >> installing debuginfo, so it would be better all round if these tools >> were to work without it. (And besides, the idea that the Windows port >> might be better in any way irks me!) I'll have a look. > > So the brute force approach is to make all vtables visible in the > dynamic symbol table. This patch does everything, I hope. It adds all vtables to the dynamic symtab, it changes the ELF reader to use the dynamic symtab, and it adds a debuginfo reader that works with every GNU/Linux system I know of. Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev-3/ OK to commit? I guess I'll need a bug ID in the Sun database too. This is https://bugs.openjdk.java.net/show_bug.cgi?id=100126 Andrew. From philissler at gmail.com Wed Mar 3 10:46:15 2010 From: philissler at gmail.com (Phil Issler) Date: Wed, 3 Mar 2010 10:46:15 -0800 (PST) Subject: generating and instantiating many classes at once causing contention Message-ID: <27772078.post@talk.nabble.com> We are generating large numbers of small classes and instantiating each one of them once and only once. It's typically a quick operation. But when many threads (more than 16) do this at approximately the same time (within 10-20 milliseconds of each other) we are seeing the threads wait inside native methods such as getDeclaredMethods0 (which is called by Class.newInstance()) and also in defineClass1 (when the generated bytecode is loaded by our custom classloader). Using YourKit, we can't determine if monitors in the native code are involved or not. Does anyone have any insight into why this might cause synchronization in the VM? Is there easy way around this contention, other than the obvious answer of generating less code (perhaps a VM setting)? Phil -- View this message in context: http://old.nabble.com/generating-and-instantiating-many-classes-at-once-causing-contention-tp27772078p27772078.html Sent from the OpenJDK Hotspot Virtual Machine mailing list archive at Nabble.com. From imdupeng at gmail.com Wed Mar 3 11:56:55 2010 From: imdupeng at gmail.com (Peng Du) Date: Wed, 03 Mar 2010 13:56:55 -0600 Subject: Question on TemplateTable::prepare_invoke In-Reply-To: <4B8E1965.6050405@sun.com> References: <4B8E1965.6050405@sun.com> Message-ID: <1267646215.23672.12.camel@witty-114b.unl.edu> Hi, John Thanks for the hint. I tried using TraceBytecodes and StopInterpreterAt, but with no luck because the order in which each class in JDK is loaded is totally nondeterministic. Therefore, the bytecode index corresponding to String.java:1218 is distinct in each run. I also tried putting NOPs in the interpreter. However, I am not very proficient in debugging HotSpot at this level. So, I couldn't stop at the right place. Given the information in my first post, can someone shed some light on what could possibly be the reason of the error? Thanks On Wed, 2010-03-03 at 00:10 -0800, John Cuthbertson wrote: > Hi Peng, > > You may have to manually examine the generated interpreter code in a > debugger to detect a register overwrite. Be warned that the code that > gets generated for a call_VM macro is quite large - I find inserting > sequences of nops helps locate the code I'm interested in. You could > also try the TraceBytecodes and StopInterpreterAt flags in debug JVM and > then do instruction stepping within a debugger. > > As for register usage/conventions with the interpreter - the best source > is probably assembler_x86.hpp. > > Regards, > > JohnC > > Peng Du wrote: > > Hello, > > > > I have a very specific question about an error I ran into today. I am > > very familiar > > with assembly programming. So, please bear with me. > > > > If I understand correctly, TemplateTable::prepare_invoke is a helper > > methods for > > the invokeXXX bytecodes. What I tried to do was to pass the oop of the > > method > > receiver to InterpreterRuntime::cache_object, which simply caches it > > in the current > > thread. > > > > Below is an excerpt in templateTable_x86_64.cpp) that I modified, the > > cache_object method in interpreterRuntime.cpp, and the cache_object > > method > > in thread.hpp: > > > > =========================================================== > > void TemplateTable::prepare_invoke(Register, Register, int) { > > const Register recv = rcx; > > ... > > // load receiver if needed (note: no return address pushed yet) > > if (load_receiver) { > > __ movl(recv, flags); > > __ andl(recv, 0xFF); > > if (TaggedStackInterpreter) __ shll(recv, 1); // index*2 > > Address recv_addr(rsp, recv, Address::times_8, > > -Interpreter::expr_offset_in_bytes(1)); > > if (is_invokedynamic) { > > __ lea(recv, recv_addr); > > } else { > > __ movptr(recv, recv_addr); > > __ verify_oop(recv); > > } > > > > // !!! cache receiver object !!! > > __ call_VM(noreg, CAST_FROM_FN_PTR(address, > > InterpreterRuntime::cache_object), recv); > > } > > ... > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > IRT_ENTRY(void, InterpreterRuntime::cache_object(JavaThread* thread, > > oop o)) > > thread->cache_object(o); > > IRT_END > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > class JavaThread { > > ... > > inline void cache_object(oop o) { _object = o; } > > > > =========================================================== > > > > However, this failed even in test_gamma with the following error: > > Error occurred during initialization of VM > > java.lang.StackOverflowError > > at java.lang.NullPointerException.(NullPointerException.java:53) > > at java.lang.NullPointerException.(NullPointerException.java:53) > > < a long list of NullPointerException same as above ... > > > at java.lang.String.(String.java:1218) > > > > It appeared to me there is infinite recursive creations of > > NullPointerException > > somewhere caused by the static initializer in String class. > > String.java:1218 > > looks like this: > > > > public static final Comparator CASE_INSENSITIVE_ORDER = new > > CaseInsensitiveComparator(); > > > > Is it because I somehow clobber the recv (rcx) register? Or can > > someone tell me > > what I did was wrong and how to fix it? Moreover, is there any > > documentation on > > the rules that how registers are used in template interpreter? > > > > > > > From Christian.Thalinger at Sun.COM Wed Mar 3 12:09:56 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 03 Mar 2010 21:09:56 +0100 Subject: Question on TemplateTable::prepare_invoke In-Reply-To: References: Message-ID: <1267646996.5285.9.camel@macbook> On Tue, 2010-03-02 at 23:24 -0600, Peng Du wrote: > void TemplateTable::prepare_invoke(Register, Register, int) { > const Register recv = rcx; > ... > // load receiver if needed (note: no return address pushed yet) > if (load_receiver) { > __ movl(recv, flags); > __ andl(recv, 0xFF); > if (TaggedStackInterpreter) __ shll(recv, 1); // index*2 > Address recv_addr(rsp, recv, Address::times_8, > -Interpreter::expr_offset_in_bytes(1)); > if (is_invokedynamic) { > __ lea(recv, recv_addr); > } else { > __ movptr(recv, recv_addr); > __ verify_oop(recv); > } > > // !!! cache receiver object !!! > __ call_VM(noreg, CAST_FROM_FN_PTR(address, > InterpreterRuntime::cache_object), recv); > } > ... > Is it because I somehow clobber the recv (rcx) register? It's very likely that you trash some registers during the call. Try to put pusha/popa around your call. -- Christian From Thomas.Rodriguez at Sun.COM Wed Mar 3 12:11:33 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 03 Mar 2010 12:11:33 -0800 Subject: Question on TemplateTable::prepare_invoke In-Reply-To: <1267646215.23672.12.camel@witty-114b.unl.edu> References: <4B8E1965.6050405@sun.com> <1267646215.23672.12.camel@witty-114b.unl.edu> Message-ID: <09F975C3-1A90-4C0D-AA46-F4BA0E1DFE38@sun.com> While call_VM generally takes care of saving off any needed state it's not implicitly safe to use every context. In particular I'd be suspicious of calling it after load_invoke_cp_cache_entry since that sets up state for use by later parts of the invoke path. tom On Mar 3, 2010, at 11:56 AM, Peng Du wrote: > Hi, John > > Thanks for the hint. I tried using TraceBytecodes and StopInterpreterAt, > but with no luck because the order in which each class in JDK is loaded > is totally nondeterministic. Therefore, the bytecode index corresponding > to String.java:1218 is distinct in each run. > > I also tried putting NOPs in the interpreter. However, I am not very > proficient in debugging HotSpot at this level. So, I couldn't stop at > the right place. > > Given the information in my first post, can someone shed some light on > what could possibly be the reason of the error? > > Thanks > > > > On Wed, 2010-03-03 at 00:10 -0800, John Cuthbertson wrote: >> Hi Peng, >> >> You may have to manually examine the generated interpreter code in a >> debugger to detect a register overwrite. Be warned that the code that >> gets generated for a call_VM macro is quite large - I find inserting >> sequences of nops helps locate the code I'm interested in. You could >> also try the TraceBytecodes and StopInterpreterAt flags in debug JVM and >> then do instruction stepping within a debugger. >> >> As for register usage/conventions with the interpreter - the best source >> is probably assembler_x86.hpp. >> >> Regards, >> >> JohnC >> >> Peng Du wrote: >>> Hello, >>> >>> I have a very specific question about an error I ran into today. I am >>> very familiar >>> with assembly programming. So, please bear with me. >>> >>> If I understand correctly, TemplateTable::prepare_invoke is a helper >>> methods for >>> the invokeXXX bytecodes. What I tried to do was to pass the oop of the >>> method >>> receiver to InterpreterRuntime::cache_object, which simply caches it >>> in the current >>> thread. >>> >>> Below is an excerpt in templateTable_x86_64.cpp) that I modified, the >>> cache_object method in interpreterRuntime.cpp, and the cache_object >>> method >>> in thread.hpp: >>> >>> =========================================================== >>> void TemplateTable::prepare_invoke(Register, Register, int) { >>> const Register recv = rcx; >>> ... >>> // load receiver if needed (note: no return address pushed yet) >>> if (load_receiver) { >>> __ movl(recv, flags); >>> __ andl(recv, 0xFF); >>> if (TaggedStackInterpreter) __ shll(recv, 1); // index*2 >>> Address recv_addr(rsp, recv, Address::times_8, >>> -Interpreter::expr_offset_in_bytes(1)); >>> if (is_invokedynamic) { >>> __ lea(recv, recv_addr); >>> } else { >>> __ movptr(recv, recv_addr); >>> __ verify_oop(recv); >>> } >>> >>> // !!! cache receiver object !!! >>> __ call_VM(noreg, CAST_FROM_FN_PTR(address, >>> InterpreterRuntime::cache_object), recv); >>> } >>> ... >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> IRT_ENTRY(void, InterpreterRuntime::cache_object(JavaThread* thread, >>> oop o)) >>> thread->cache_object(o); >>> IRT_END >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> class JavaThread { >>> ... >>> inline void cache_object(oop o) { _object = o; } >>> >>> =========================================================== >>> >>> However, this failed even in test_gamma with the following error: >>> Error occurred during initialization of VM >>> java.lang.StackOverflowError >>> at java.lang.NullPointerException.(NullPointerException.java:53) >>> at java.lang.NullPointerException.(NullPointerException.java:53) >>> < a long list of NullPointerException same as above ... > >>> at java.lang.String.(String.java:1218) >>> >>> It appeared to me there is infinite recursive creations of >>> NullPointerException >>> somewhere caused by the static initializer in String class. >>> String.java:1218 >>> looks like this: >>> >>> public static final Comparator CASE_INSENSITIVE_ORDER = new >>> CaseInsensitiveComparator(); >>> >>> Is it because I somehow clobber the recv (rcx) register? Or can >>> someone tell me >>> what I did was wrong and how to fix it? Moreover, is there any >>> documentation on >>> the rules that how registers are used in template interpreter? >>> >>> >>> >> > > From imdupeng at gmail.com Wed Mar 3 12:33:51 2010 From: imdupeng at gmail.com (Peng Du) Date: Wed, 03 Mar 2010 14:33:51 -0600 Subject: Question on TemplateTable::prepare_invoke In-Reply-To: <1267646996.5285.9.camel@macbook> References: <1267646996.5285.9.camel@macbook> Message-ID: <1267648431.23672.22.camel@witty-114b.unl.edu> Hi, Tom and Christian You're right. The call indeed trashs some regs because pusha+popa solved the problem. This seems a little brute-force though. Do you have a good way to trace down which regs are trashed? Thanks a lot! On Wed, 2010-03-03 at 12:11 -0800, Tom Rodriguez wrote: > While call_VM generally takes care of saving off any needed state it's > not implicitly safe to use every context. In particular I'd be suspicious > of calling it after load_invoke_cp_cache_entry since that sets up state > for use by later parts of the invoke path. > > tom > On Wed, 2010-03-03 at 21:09 +0100, Christian Thalinger wrote: > On Tue, 2010-03-02 at 23:24 -0600, Peng Du wrote: > > void TemplateTable::prepare_invoke(Register, Register, int) { > > const Register recv = rcx; > > ... > > // load receiver if needed (note: no return address pushed yet) > > if (load_receiver) { > > __ movl(recv, flags); > > __ andl(recv, 0xFF); > > if (TaggedStackInterpreter) __ shll(recv, 1); // index*2 > > Address recv_addr(rsp, recv, Address::times_8, > > -Interpreter::expr_offset_in_bytes(1)); > > if (is_invokedynamic) { > > __ lea(recv, recv_addr); > > } else { > > __ movptr(recv, recv_addr); > > __ verify_oop(recv); > > } > > > > // !!! cache receiver object !!! > > __ call_VM(noreg, CAST_FROM_FN_PTR(address, > > InterpreterRuntime::cache_object), recv); > > } > > ... > > > Is it because I somehow clobber the recv (rcx) register? > > It's very likely that you trash some registers during the call. Try to > put pusha/popa around your call. > > -- Christian > From aph at redhat.com Thu Mar 4 07:58:03 2010 From: aph at redhat.com (Andrew Haley) Date: Thu, 04 Mar 2010 15:58:03 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B8456BD.1000101@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> Message-ID: <4B8FD88B.3050709@redhat.com> This bug causes OpenOffice to crash on Linux systems. Webrev at http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev/ Andrew. From Thomas.Rodriguez at Sun.COM Thu Mar 4 10:54:49 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Thu, 04 Mar 2010 10:54:49 -0800 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <4B8E7DC2.2010905@redhat.com> References: <4B1FC407.6010405@redhat.com> <4B477E05.5050207@redhat.com> <4B486278.9040005@redhat.com> <448B68EA-1FE2-430C-A534-A8598652C046@Sun.COM> <4B55D97D.4020001@redhat.com> <5D1BE1E0-B1D9-465F-A29F-A46802BD7F43@Sun.COM> <4B56D7E0.6020702@redhat.com> <401A9C44-0A14-49AB-A771-A049BC04AE12@Sun.COM> <4B8E7DC2.2010905@redhat.com> Message-ID: The changes look good to me. I created 6932270 for this and applied your changes to our workspace. I'll run some SA specific tests on it first and then push it using JPRT assuming the results are clean. The webrev of the changes are http://cr.openjdk.java.net/~never/6932270. tom On Mar 3, 2010, at 7:18 AM, Andrew Haley wrote: > On 01/20/2010 05:35 PM, Tom Rodriguez wrote: >> >> On Jan 20, 2010, at 2:16 AM, Andrew Haley wrote: >> >>> On 01/19/2010 07:43 PM, Tom Rodriguez wrote: >>> >>>> So do you want to pursue making the SA work with a stripped >>>> libjvm.so or is requiring debug info to be installed acceptable? >>>> Sorry if I made this more complicated than you wanted. I think your >>>> original change is fine, but if the norm is being stripped then >>>> making these tools work in that situation would be good. >>> >>> Clearly it would be. Java programmers on Linux systems aren't used to >>> installing debuginfo, so it would be better all round if these tools >>> were to work without it. (And besides, the idea that the Windows port >>> might be better in any way irks me!) I'll have a look. >> >> So the brute force approach is to make all vtables visible in the >> dynamic symbol table. > > This patch does everything, I hope. It adds all vtables to the > dynamic symtab, it changes the ELF reader to use the dynamic symtab, > and it adds a debuginfo reader that works with every GNU/Linux system > I know of. > > Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev-3/ > > OK to commit? I guess I'll need a bug ID in the Sun database too. > > This is https://bugs.openjdk.java.net/show_bug.cgi?id=100126 > > Andrew. From David.Holmes at Sun.COM Thu Mar 4 14:18:39 2010 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 05 Mar 2010 08:18:39 +1000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B8FD88B.3050709@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> Message-ID: <4B9031BF.60909@sun.com> Andrew, Andrew Haley said the following on 03/05/10 01:58: > This bug causes OpenOffice to crash on Linux systems. > > Webrev at > http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev/ We don't use the C++ streams in Hotspot code. I don't know why (historical no doubt) and I don't know if it can actually cause problems, but we don't do it. I can't comment on the technical aspect of the changes. Cheers, David Holmes From Coleen.Phillimore at Sun.COM Thu Mar 4 14:42:21 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Thu, 04 Mar 2010 17:42:21 -0500 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B9031BF.60909@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> Message-ID: <4B90374D.4040806@sun.com> Hi, I'm also reviewing this change but I also had the same question about iostream. I don't know the history either. We have a similar function in os_linux.cpp called find_vma() which uses standard C file io. You could rewrite get_stack_bounds() if there's a reason to. The other thing, || *jaxws/jaxws.properties *is checked into a different repository (not the hotspot one). Also, I believe you need to add comments from the discussion in the emails in the new os_linux.cpp functions, because I for one will lose the email connection but it would be useful to preserve the reason for this change. Lastly, Andrew, do you need a sun employee to check this in? I will do this once we resolve the issues above. Thanks, Coleen David Holmes - Sun Microsystems wrote: > Andrew, > > Andrew Haley said the following on 03/05/10 01:58: >> This bug causes OpenOffice to crash on Linux systems. >> >> Webrev at >> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev/ > > We don't use the C++ streams in Hotspot code. I don't know why > (historical no doubt) and I don't know if it can actually cause > problems, but we don't do it. > > I can't comment on the technical aspect of the changes. > > Cheers, > David Holmes From aph at redhat.com Fri Mar 5 01:32:18 2010 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Mar 2010 09:32:18 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B9031BF.60909@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> Message-ID: <4B90CFA2.6090603@redhat.com> On 03/04/2010 10:18 PM, David Holmes - Sun Microsystems wrote: > Andrew, > > Andrew Haley said the following on 03/05/10 01:58: >> This bug causes OpenOffice to crash on Linux systems. >> >> Webrev at >> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev/ > > We don't use the C++ streams in Hotspot code. I don't know why > (historical no doubt) and I don't know if it can actually cause > problems, but we don't do it. I have no problem rewriting this to use C conversions instead. Andrew. From aph at redhat.com Fri Mar 5 01:35:50 2010 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Mar 2010 09:35:50 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B90374D.4040806@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> Message-ID: <4B90D076.9050604@redhat.com> On 03/04/2010 10:42 PM, Coleen Phillimore wrote: > I'm also reviewing this change but I also had the same question about > iostream. I don't know the history either. We have a similar function > in os_linux.cpp called find_vma() which uses standard C file io. You > could rewrite get_stack_bounds() if there's a reason to. I'll look at ind_vma() and do that. > The other thing, || *jaxws/jaxws.properties *is checked into a different > repository (not the hotspot one). I'm very sorry, that change to jaxws.properties should not have been included in the webrev. kenai.com fell off the Net yesterday and I couldn't build without this change. > Also, I believe you need to add comments from the discussion in the > emails in the new os_linux.cpp functions, because I for one will lose > the email connection but it would be useful to preserve the reason for > this change. > > Lastly, Andrew, do you need a sun employee to check this in? I will do > this once we resolve the issues above. I have push access. Andrew. From David.Holmes at Sun.COM Fri Mar 5 02:04:54 2010 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 05 Mar 2010 20:04:54 +1000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B90D076.9050604@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B90D076.9050604@redhat.com> Message-ID: <4B90D746.1060908@sun.com> Andrew Haley said the following on 03/05/10 19:35: > On 03/04/2010 10:42 PM, Coleen Phillimore wrote: >> Lastly, Andrew, do you need a sun employee to check this in? I will do >> this once we resolve the issues above. > > I have push access. But this needs to put through JPRT, which AFAIK is not possible externally. David From aph at redhat.com Fri Mar 5 02:41:14 2010 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Mar 2010 10:41:14 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B90D746.1060908@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B90D076.9050604@redhat.com> <4B90D746.1060908@sun.com> Message-ID: <4B90DFCA.8000105@redhat.com> On 03/05/2010 10:04 AM, David Holmes - Sun Microsystems wrote: > Andrew Haley said the following on 03/05/10 19:35: >> On 03/04/2010 10:42 PM, Coleen Phillimore wrote: >>> Lastly, Andrew, do you need a sun employee to check this in? I will do >>> this once we resolve the issues above. >> >> I have push access. > > But this needs to put through JPRT, which AFAIK is not possible externally. OK. I'll rewrite and resubmit. Thanks, Andrew. From Coleen.Phillimore at Sun.COM Fri Mar 5 04:55:29 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Fri, 05 Mar 2010 07:55:29 -0500 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B90DFCA.8000105@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B90D076.9050604@redhat.com> <4B90D746.1060908@sun.com> <4B90DFCA.8000105@redhat.com> Message-ID: <4B90FF41.5090406@sun.com> Andrew, Can you submit through JPRT? Also, part of my email requested comments around the new os_linux.cpp functions. Can you send out another code review? Thanks, Coleen Andrew Haley wrote: > On 03/05/2010 10:04 AM, David Holmes - Sun Microsystems wrote: > >> Andrew Haley said the following on 03/05/10 19:35: >> >>> On 03/04/2010 10:42 PM, Coleen Phillimore wrote: >>> >>>> Lastly, Andrew, do you need a sun employee to check this in? I will do >>>> this once we resolve the issues above. >>>> >>> I have push access. >>> >> But this needs to put through JPRT, which AFAIK is not possible externally. >> > > OK. I'll rewrite and resubmit. > > Thanks, > Andrew. > From aph at redhat.com Fri Mar 5 04:58:42 2010 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Mar 2010 12:58:42 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B90FF41.5090406@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B90D076.9050604@redhat.com> <4B90D746.1060908@sun.com> <4B90DFCA.8000105@redhat.com> <4B90FF41.5090406@sun.com> Message-ID: <4B910002.1080608@redhat.com> On 03/05/2010 12:55 PM, Coleen Phillimore wrote: > > Can you submit through JPRT? I presume not. > Also, part of my email requested comments around the new os_linux.cpp > functions. Can you send out another code review? OK. Andrew. From Paul.Hohensee at Sun.COM Fri Mar 5 07:01:42 2010 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Fri, 05 Mar 2010 10:01:42 -0500 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B90374D.4040806@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> Message-ID: <4B911CD6.7040301@sun.com> I suspect we don't use iostream for the same reason we didn't use templates, namely when Hotspot was first implemented implementations were inconsistent across various C++ compilers. Paul Coleen Phillimore wrote: > Hi, > I'm also reviewing this change but I also had the same question about > iostream. I don't know the history either. We have a similar > function in os_linux.cpp called find_vma() which uses standard C file > io. You could rewrite get_stack_bounds() if there's a reason to. > > The other thing, || *jaxws/jaxws.properties *is checked into a > different repository (not the hotspot one). > > Also, I believe you need to add comments from the discussion in the > emails in the new os_linux.cpp functions, because I for one will lose > the email connection but it would be useful to preserve the reason for > this change. > > Lastly, Andrew, do you need a sun employee to check this in? I will > do this once we resolve the issues above. > > Thanks, > Coleen > > David Holmes - Sun Microsystems wrote: >> Andrew, >> >> Andrew Haley said the following on 03/05/10 01:58: >>> This bug causes OpenOffice to crash on Linux systems. >>> >>> Webrev at >>> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev/ >> >> We don't use the C++ streams in Hotspot code. I don't know why >> (historical no doubt) and I don't know if it can actually cause >> problems, but we don't do it. >> >> I can't comment on the technical aspect of the changes. >> >> Cheers, >> David Holmes > From aph at redhat.com Fri Mar 5 08:35:06 2010 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Mar 2010 16:35:06 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B90374D.4040806@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> Message-ID: <4B9132BA.8050206@redhat.com> On 03/04/2010 10:42 PM, Coleen Phillimore wrote: > Hi, > I'm also reviewing this change but I also had the same question about > iostream. I don't know the history either. We have a similar function > in os_linux.cpp called find_vma() which uses standard C file io. You > could rewrite get_stack_bounds() if there's a reason to. > > The other thing, || *jaxws/jaxws.properties *is checked into a different > repository (not the hotspot one). > > Also, I believe you need to add comments from the discussion in the > emails in the new os_linux.cpp functions, because I for one will lose > the email connection but it would be useful to preserve the reason for > this change. > > Lastly, Andrew, do you need a sun employee to check this in? I will do > this once we resolve the issues above. Done. I also made the patch a little more robust: at the moment Linux pthreads doesn't use growable mappings for thread stacks so there's no need to munmap() the guard pages. If ever pthreads does switch over to using growable mappings I'm pretty sure this code will still work. Andrew. http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-2/ From Coleen.Phillimore at Sun.COM Fri Mar 5 09:25:19 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Fri, 05 Mar 2010 12:25:19 -0500 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B913A1B.1060701@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> Message-ID: <4B913E7F.8010803@sun.com> This looks good to me, there are a couple of questions. Can you use /proc/self/maps instead of getting the tid? Also there's a 'my' instead of 'by' in the comments. Thank you for adding all the comments. Coleen Keith McGuigan wrote: > Andrew Haley wrote: >> On 03/04/2010 10:42 PM, Coleen Phillimore wrote: >> >>> Hi, >>> I'm also reviewing this change but I also had the same question about >>> iostream. I don't know the history either. We have a similar function >>> in os_linux.cpp called find_vma() which uses standard C file io. You >>> could rewrite get_stack_bounds() if there's a reason to. >>> >>> The other thing, || *jaxws/jaxws.properties *is checked into a >>> different >>> repository (not the hotspot one). >>> >>> Also, I believe you need to add comments from the discussion in the >>> emails in the new os_linux.cpp functions, because I for one will lose >>> the email connection but it would be useful to preserve the reason for >>> this change. >>> >>> Lastly, Andrew, do you need a sun employee to check this in? I will do >>> this once we resolve the issues above. >>> >> >> Done. I also made the patch a little more robust: at the moment Linux >> pthreads doesn't use growable mappings for thread stacks so there's no >> need to munmap() the guard pages. If ever pthreads does switch over to >> using growable mappings I'm pretty sure this code will still work. >> >> Andrew. >> >> >> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-2/ >> > > Looks good to me. Thanks! > > -- > - Keith > From aph at redhat.com Fri Mar 5 09:59:15 2010 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Mar 2010 17:59:15 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B913E7F.8010803@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> Message-ID: <4B914673.1090200@redhat.com> On 03/05/2010 05:25 PM, Coleen Phillimore wrote: > > This looks good to me, there are a couple of questions. Can you use > /proc/self/maps instead of getting the tid? Sure. I was being defensive because the manpage says: /proc/self This directory refers to the process accessing the /proc filesystem, and is identical to the /proc directory named by the process ID of the same process. which I thought meant the PID rather than the TID. However, the page is misleading: I just checked and /proc/self refers to the TID. (Not that it really matters, as the mappings will mostly be the same anyway.) > Also there's a 'my' instead of 'by' in the comments. Fixed. http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-3 By the way, I have a good regression test for this. Should I submit that too? Andrew. From Coleen.Phillimore at Sun.COM Fri Mar 5 05:18:39 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Fri, 05 Mar 2010 08:18:39 -0500 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B914673.1090200@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> Message-ID: <4B9104AF.5010106@sun.com> Yes, definitely send the test case too. thanks, Coleen Andrew Haley wrote: > On 03/05/2010 05:25 PM, Coleen Phillimore wrote: > >> This looks good to me, there are a couple of questions. Can you use >> /proc/self/maps instead of getting the tid? >> > > Sure. I was being defensive because the manpage says: > > /proc/self > > This directory refers to the process accessing the /proc > filesystem, and is identical to the /proc directory named by the > process ID of the same process. > > which I thought meant the PID rather than the TID. However, the page > is misleading: I just checked and /proc/self refers to the TID. (Not > that it really matters, as the mappings will mostly be the same > anyway.) > > >> Also there's a 'my' instead of 'by' in the comments. >> > > Fixed. > > http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-3 > > By the way, I have a good regression test for this. Should I submit > that too? > > Andrew. > From Ulf.Zibis at gmx.de Fri Mar 5 13:47:49 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 05 Mar 2010 22:47:49 +0100 Subject: Assertions in static blocks ? In-Reply-To: <4B756945.1090600@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> Message-ID: <4B917C05.3020309@gmx.de> No response ?? :-( I've filed a bug: internal review ID of 1730072 -Ulf Am 12.02.2010 15:44, schrieb Ulf Zibis: > Am 12.02.2010 15:06, schrieb Ulf Zibis: >> Hi, >> >> in the following example, I have an assert statement in a static >> block of my class. >> >> If accessing the static final constants from another class, the >> static block is not executed. >> This causes the assertions to remain un-proofed, even if -ea -esa is >> set. >> >> Is that correct ? > > If yes, javac should claim the code as never reached. > >> >> IMO, assertions should always run, if -ea -esa is set. >> >> -Ulf >> > > -Ulf > > > From - Fri Feb 12 16:25:03 2010 > X-Account-Key: account2 > X-UIDL: 5de5c7b81a751aec6aed7ffb66ca9b90 > X-Mozilla-Status: 0000 > X-Mozilla-Status2: 00000000 > X-Mozilla-Keys: > X-Symantec-TimeoutProtection: 0 > X-Symantec-TimeoutProtection: 1 > X-Symantec-TimeoutProtection: 2 > Return-Path: > X-Flags: 1001 > Delivered-To: GMX delivery to ulf.zibis at gmx.de > Received: (qmail invoked by alias); 12 Feb 2010 15:12:59 -0000 > Received: from brmea-mail-2.Sun.COM (EHLO brmea-mail-2.sun.com) > [192.18.98.43] > by mx0.gmx.net (mx002) with SMTP; 12 Feb 2010 16:12:59 +0100 > Received: from fe-amer-09.sun.com ([192.18.109.79]) > by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id > o1CFCw62027512 > for ; Fri, 12 Feb 2010 15:12:58 GMT > MIME-version: 1.0 > Content-transfer-encoding: 7BIT > Content-type: text/plain; CHARSET=US-ASCII; format=flowed > Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com > (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) > id <0KXQ00800HZH3I00 at mail-amer.sun.com> for Ulf.Zibis at gmx.de; Fri, > 12 Feb 2010 08:12:58 -0700 (MST) > Received: from [129.150.65.45] ([unknown] [129.150.65.45]) > by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit > (built Jul 2 2009)) with ESMTPSA id > <0KXQ00GTLI9L1V60 at mail-amer.sun.com>; Fri, > 12 Feb 2010 08:12:58 -0700 (MST) > Date: Fri, 12 Feb 2010 10:12:58 -0500 > From: Keith McGuigan > Subject: Re: Assertions in static blocks ? > In-reply-to: <4B756071.4000104 at gmx.de> > Sender: Keith.McGuigan at Sun.COM > To: Ulf Zibis > Cc: compiler-dev at openjdk.java.net, hotspot > Message-id: <4B756FFA.9000806 at sun.com> > References: <4B756071.4000104 at gmx.de> > User-Agent: Thunderbird 2.0.0.23 (X11/20090817) > X-GMX-Antivirus: 0 (no virus found) > X-GMX-Antispam: 0 (Mail was not recognized as spam); > Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDmtyzoN37OXMt9GpYHsrWRra7o+psEYuNg/dar > > zWRIb1W0k0rd15IZBf9O4nqjKYX9PrVGG/zPEENchmY89mOrfO0W57R8iRtiMheMiqQP1ym7bl2H > > PZZzg==V1; > X-GMX-UID: ylpHc/1fPjlsBVAdATU22s0zMTE2Ncn9 > > > Hi Ulf - > > Accessing a constant static field in a class does not trigger class > initialization, so your initializer is probably just not being run. > > See > http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19075 > > > -- > - Keith > > Ulf Zibis wrote: >> Hi, >> >> in the following example, I have an assert statement in a static >> block of my class. >> >> If accessing the static final constants from another class, the >> static block is not executed. >> This causes the assertions to remain un-proofed, even if -ea -esa is >> set. >> >> Is that correct ? >> >> IMO, assertions should always run, if -ea -esa is set. >> >> -Ulf >> >> >> >> package sun.nio.cs.ext; >> >> import static sun.nio.cs.CharsetMapping.*; >> >> /** >> * >> * @author Ulf Zibis, Cologne CoSoCo.de >> */ >> class EUC_TWMapping3 extends EUC_TWMapping { >> static final short PL0_5_B2C_RANGE = 0x2300; // plane 0, 5 b2c range >> static final short PLANE_B2C_RANGE = 0x1f00; // plane 2..4, 6..15 >> b2c range >> >> // TODO: file bug: static block should run, if assertions are enabled. >> static { >> // assert plane offsets and content >> for (int p=0, range, offset=0; p> range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >> for (int i=range; i> assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >> // static block should run, if assertions are enabled. For test >> uncomment following line >> // System.out.printf("offset: %d, range: %d, >> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >> assert (offset += range) <= Character.MAX_VALUE + 1; >> } >> } >> >> // WORKAROUND: >> // static int offset = 0; // assert from calling context to force >> static block to process >> // static { >> // // assert plane offsets and content >> // for (int p=0, range; p> // range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >> // for (int i=range; i> // assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >> //// static block should run, if assertions are enabled. For test >> uncomment following line >> //// System.out.printf("offset: %d, range: %d, >> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >> // assert (offset += range) <= Character.MAX_VALUE + 1; >> // } >> //// static block should run, if assertions are enabled. For test >> uncomment following line >> //// assert false; >> // } >> } >> >> >> package sun.nio.cs.ext; >> >> /** >> * >> * @author Ulf Zibis, Cologne CoSoCo.de >> */ >> public class AssertTest { >> >> public static void main(String... args) { >> // static block in EUC_TWMapping3 should run, if assertions are enabled. >> System.out.println(EUC_TWMapping3.PLANE_B2C_RANGE); >> // WORKAROUND: For test uncomment following line >> // assert EUC_TWMapping3.offset > 0; // force assertion, TODO: >> JDK bug ? >> } >> } >> >> > > From neal at gafter.com Fri Mar 5 13:59:34 2010 From: neal at gafter.com (Neal Gafter) Date: Fri, 5 Mar 2010 13:59:34 -0800 Subject: Assertions in static blocks ? In-Reply-To: <4B917C05.3020309@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> Message-ID: <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> On Fri, Mar 5, 2010 at 1:47 PM, Ulf Zibis wrote: > No response ?? :-( > Keith's response is correct. An assertion in a method only occurs when the method is executed. An assertion in a constructor only occurs when the constructor is called. An assertion in a static initializer only occurs when the class is statically initialized. Accessing a constant of the class does not initialize the class. So there is no bug. Cheers, Neal > I've filed a bug: > > internal review ID of 1730072 > > > -Ulf > > > > Am 12.02.2010 15:44, schrieb Ulf Zibis: > >> Am 12.02.2010 15:06, schrieb Ulf Zibis: >> >>> Hi, >>> >>> in the following example, I have an assert statement in a static block of >>> my class. >>> >>> If accessing the static final constants from another class, the static >>> block is not executed. >>> This causes the assertions to remain un-proofed, even if -ea -esa is set. >>> >>> Is that correct ? >>> >> >> If yes, javac should claim the code as never reached. >> >> >>> IMO, assertions should always run, if -ea -esa is set. >>> >>> -Ulf >>> >>> >> -Ulf >> >> >> From - Fri Feb 12 16:25:03 2010 >> X-Account-Key: account2 >> X-UIDL: 5de5c7b81a751aec6aed7ffb66ca9b90 >> X-Mozilla-Status: 0000 >> X-Mozilla-Status2: 00000000 >> X-Mozilla-Keys: >> X-Symantec-TimeoutProtection: 0 >> X-Symantec-TimeoutProtection: 1 >> X-Symantec-TimeoutProtection: 2 >> Return-Path: >> X-Flags: 1001 >> Delivered-To: GMX delivery to ulf.zibis at gmx.de >> Received: (qmail invoked by alias); 12 Feb 2010 15:12:59 -0000 >> Received: from brmea-mail-2.Sun.COM (EHLO brmea-mail-2.sun.com) >> [192.18.98.43] >> by mx0.gmx.net (mx002) with SMTP; 12 Feb 2010 16:12:59 +0100 >> Received: from fe-amer-09.sun.com ([192.18.109.79]) >> by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id >> o1CFCw62027512 >> for ; Fri, 12 Feb 2010 15:12:58 GMT >> MIME-version: 1.0 >> Content-transfer-encoding: 7BIT >> Content-type: text/plain; CHARSET=US-ASCII; format=flowed >> Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com >> (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) >> id <0KXQ00800HZH3I00 at mail-amer.sun.com> for Ulf.Zibis at gmx.de; Fri, >> 12 Feb 2010 08:12:58 -0700 (MST) >> Received: from [129.150.65.45] ([unknown] [129.150.65.45]) >> by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit >> (built Jul 2 2009)) with ESMTPSA id <0KXQ00GTLI9L1V60 at mail-amer.sun.com>; >> Fri, >> 12 Feb 2010 08:12:58 -0700 (MST) >> Date: Fri, 12 Feb 2010 10:12:58 -0500 >> From: Keith McGuigan >> Subject: Re: Assertions in static blocks ? >> In-reply-to: <4B756071.4000104 at gmx.de> >> Sender: Keith.McGuigan at Sun.COM >> To: Ulf Zibis >> Cc: compiler-dev at openjdk.java.net, hotspot >> Message-id: <4B756FFA.9000806 at sun.com> >> References: <4B756071.4000104 at gmx.de> >> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) >> X-GMX-Antivirus: 0 (no virus found) >> X-GMX-Antispam: 0 (Mail was not recognized as spam); >> Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDmtyzoN37OXMt9GpYHsrWRra7o+psEYuNg/dar >> >> zWRIb1W0k0rd15IZBf9O4nqjKYX9PrVGG/zPEENchmY89mOrfO0W57R8iRtiMheMiqQP1ym7bl2H >> >> PZZzg==V1; >> X-GMX-UID: ylpHc/1fPjlsBVAdATU22s0zMTE2Ncn9 >> >> >> >> Hi Ulf - >> >> Accessing a constant static field in a class does not trigger class >> initialization, so your initializer is probably just not being run. >> >> See >> http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19075 >> >> -- >> - Keith >> >> Ulf Zibis wrote: >> >>> Hi, >>> >>> in the following example, I have an assert statement in a static block of >>> my class. >>> >>> If accessing the static final constants from another class, the static >>> block is not executed. >>> This causes the assertions to remain un-proofed, even if -ea -esa is set. >>> >>> Is that correct ? >>> >>> IMO, assertions should always run, if -ea -esa is set. >>> >>> -Ulf >>> >>> >>> >>> package sun.nio.cs.ext; >>> >>> import static sun.nio.cs.CharsetMapping.*; >>> >>> /** >>> * >>> * @author Ulf Zibis, Cologne CoSoCo.de >>> */ >>> class EUC_TWMapping3 extends EUC_TWMapping { >>> static final short PL0_5_B2C_RANGE = 0x2300; // plane 0, 5 b2c range >>> static final short PLANE_B2C_RANGE = 0x1f00; // plane 2..4, 6..15 b2c >>> range >>> >>> // TODO: file bug: static block should run, if assertions are enabled. >>> static { >>> // assert plane offsets and content >>> for (int p=0, range, offset=0; p>> range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >>> for (int i=range; i>> assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >>> // static block should run, if assertions are enabled. For test uncomment >>> following line >>> // System.out.printf("offset: %d, range: %d, b2c[p].length(): >>> %d%n", offset, range, b2c[p].length()); >>> assert (offset += range) <= Character.MAX_VALUE + 1; >>> } >>> } >>> >>> // WORKAROUND: >>> // static int offset = 0; // assert from calling context to force >>> static block to process >>> // static { >>> // // assert plane offsets and content >>> // for (int p=0, range; p>> // range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >>> // for (int i=range; i>> // assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >>> //// static block should run, if assertions are enabled. For test >>> uncomment following line >>> //// System.out.printf("offset: %d, range: %d, >>> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >>> // assert (offset += range) <= Character.MAX_VALUE + 1; >>> // } >>> //// static block should run, if assertions are enabled. For test >>> uncomment following line >>> //// assert false; >>> // } >>> } >>> >>> >>> package sun.nio.cs.ext; >>> >>> /** >>> * >>> * @author Ulf Zibis, Cologne CoSoCo.de >>> */ >>> public class AssertTest { >>> >>> public static void main(String... args) { >>> // static block in EUC_TWMapping3 should run, if assertions are enabled. >>> System.out.println(EUC_TWMapping3.PLANE_B2C_RANGE); >>> // WORKAROUND: For test uncomment following line >>> // assert EUC_TWMapping3.offset > 0; // force assertion, TODO: JDK >>> bug ? >>> } >>> } >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100305/efe20f24/attachment.html From Ulf.Zibis at gmx.de Fri Mar 5 15:08:16 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 06 Mar 2010 00:08:16 +0100 Subject: Assertions in static blocks ? In-Reply-To: <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> Message-ID: <4B918EE0.7010709@gmx.de> Neal, Keith, thanks for your answer. ... but shouldn't javac claim, that there the code in the static block will be *never reached*, if there is no trigger to run it? -Ulf Am 05.03.2010 22:59, schrieb Neal Gafter: > On Fri, Mar 5, 2010 at 1:47 PM, Ulf Zibis > wrote: > > No response ?? :-( > > > Keith's response is correct. An assertion in a method only occurs > when the method is executed. An assertion in a constructor only > occurs when the constructor is called. An assertion in a static > initializer only occurs when the class is statically initialized. > Accessing a constant of the class does not initialize the class. So > there is no bug. > > Cheers, > Neal > > > I've filed a bug: > > internal review ID of 1730072 > > > -Ulf > > > > Am 12.02.2010 15:44, schrieb Ulf Zibis: > > Am 12.02.2010 15:06, schrieb Ulf Zibis: > > Hi, > > in the following example, I have an assert statement in a > static block of my class. > > If accessing the static final constants from another > class, the static block is not executed. > This causes the assertions to remain un-proofed, even if > -ea -esa is set. > > Is that correct ? > > > If yes, javac should claim the code as never reached. > > > IMO, assertions should always run, if -ea -esa is set. > > -Ulf > > > -Ulf > > > >From - Fri Feb 12 16:25:03 2010 > X-Account-Key: account2 > X-UIDL: 5de5c7b81a751aec6aed7ffb66ca9b90 > X-Mozilla-Status: 0000 > X-Mozilla-Status2: 00000000 > X-Mozilla-Keys: > X-Symantec-TimeoutProtection: 0 > X-Symantec-TimeoutProtection: 1 > X-Symantec-TimeoutProtection: 2 > Return-Path: > X-Flags: 1001 > Delivered-To: GMX delivery to ulf.zibis at gmx.de > > Received: (qmail invoked by alias); 12 Feb 2010 15:12:59 -0000 > Received: from brmea-mail-2.Sun.COM > (EHLO brmea-mail-2.sun.com > ) [192.18.98.43] > by mx0.gmx.net (mx002) with SMTP; 12 Feb > 2010 16:12:59 +0100 > Received: from fe-amer-09.sun.com > ([192.18.109.79]) > by brmea-mail-2.sun.com > (8.13.6+Sun/8.12.9) with ESMTP id o1CFCw62027512 > for >; Fri, 12 > Feb 2010 15:12:58 GMT > MIME-version: 1.0 > Content-transfer-encoding: 7BIT > Content-type: text/plain; CHARSET=US-ASCII; format=flowed > Received: from conversion-daemon.mail-amer.sun.com > by > mail-amer.sun.com > (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built > Jul 2 2009)) > id <0KXQ00800HZH3I00 at mail-amer.sun.com > > for > Ulf.Zibis at gmx.de ; Fri, > 12 Feb 2010 08:12:58 -0700 (MST) > Received: from [129.150.65.45] ([unknown] [129.150.65.45]) > by mail-amer.sun.com (Sun Java(tm) > System Messaging Server 7u2-7.04 64bit > (built Jul 2 2009)) with ESMTPSA id > <0KXQ00GTLI9L1V60 at mail-amer.sun.com > >; Fri, > 12 Feb 2010 08:12:58 -0700 (MST) > Date: Fri, 12 Feb 2010 10:12:58 -0500 > From: Keith McGuigan > Subject: Re: Assertions in static blocks ? > In-reply-to: <4B756071.4000104 at gmx.de > > > Sender: Keith.McGuigan at Sun.COM > To: Ulf Zibis > > Cc: compiler-dev at openjdk.java.net > , hotspot > > > Message-id: <4B756FFA.9000806 at sun.com > > > References: <4B756071.4000104 at gmx.de > > > User-Agent: Thunderbird 2.0.0.23 (X11/20090817) > X-GMX-Antivirus: 0 (no virus found) > X-GMX-Antispam: 0 (Mail was not recognized as spam); > Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDmtyzoN37OXMt9GpYHsrWRra7o+psEYuNg/dar > > zWRIb1W0k0rd15IZBf9O4nqjKYX9PrVGG/zPEENchmY89mOrfO0W57R8iRtiMheMiqQP1ym7bl2H > > PZZzg==V1; > X-GMX-UID: ylpHc/1fPjlsBVAdATU22s0zMTE2Ncn9 > > > > Hi Ulf - > > Accessing a constant static field in a class does not trigger > class initialization, so your initializer is probably just not > being run. > > See > http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19075 > > > -- > - Keith > > Ulf Zibis wrote: > > Hi, > > in the following example, I have an assert statement in a > static block of my class. > > If accessing the static final constants from another > class, the static block is not executed. > This causes the assertions to remain un-proofed, even if > -ea -esa is set. > > Is that correct ? > > IMO, assertions should always run, if -ea -esa is set. > > -Ulf > > > > package sun.nio.cs.ext; > > import static sun.nio.cs.CharsetMapping.*; > > /** > * > * @author Ulf Zibis, Cologne CoSoCo.de > */ > class EUC_TWMapping3 extends EUC_TWMapping { > static final short PL0_5_B2C_RANGE = 0x2300; // plane > 0, 5 b2c range > static final short PLANE_B2C_RANGE = 0x1f00; // plane > 2..4, 6..15 b2c range > > // TODO: file bug: static block should run, if assertions > are enabled. > static { > // assert plane offsets and content > for (int p=0, range, offset=0; p range = p % 4 == 0 ? PL0_5_B2C_RANGE : > PLANE_B2C_RANGE; > for (int i=range; i assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; > // static block should run, if assertions are enabled. For > test uncomment following line > // System.out.printf("offset: %d, range: %d, > b2c[p].length(): %d%n", offset, range, b2c[p].length()); > assert (offset += range) <= Character.MAX_VALUE > + 1; > } > } > > // WORKAROUND: > // static int offset = 0; // assert from calling > context to force static block to process > // static { > // // assert plane offsets and content > // for (int p=0, range; p // range = p % 4 == 0 ? PL0_5_B2C_RANGE : > PLANE_B2C_RANGE; > // for (int i=range; i // assert b2c[p].charAt(i) == > UNMAPPABLE_DECODING; > //// static block should run, if assertions are enabled. > For test uncomment following line > //// System.out.printf("offset: %d, range: %d, > b2c[p].length(): %d%n", offset, range, b2c[p].length()); > // assert (offset += range) <= > Character.MAX_VALUE + 1; > // } > //// static block should run, if assertions are enabled. > For test uncomment following line > //// assert false; > // } > } > > > package sun.nio.cs.ext; > > /** > * > * @author Ulf Zibis, Cologne CoSoCo.de > */ > public class AssertTest { > > public static void main(String... args) { > // static block in EUC_TWMapping3 should run, if > assertions are enabled. > System.out.println(EUC_TWMapping3.PLANE_B2C_RANGE); > // WORKAROUND: For test uncomment following line > // assert EUC_TWMapping3.offset > 0; // force > assertion, TODO: JDK bug ? > } > } > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100306/cd135c4b/attachment-0001.html From Jonathan.Gibbons at Sun.COM Fri Mar 5 15:31:23 2010 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 05 Mar 2010 15:31:23 -0800 Subject: Assertions in static blocks ? In-Reply-To: <4B918EE0.7010709@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> Message-ID: <4B91944B.6010609@sun.com> There is a trigger -- you're just not using it. "An assertion in a static initializer only occurs when the class is statically initialized. " -- Jon Ulf Zibis wrote: > Neal, Keith, thanks for your answer. > > ... but shouldn't javac claim, that there the code in the static block > will be *never reached*, if there is no trigger to run it? > > -Ulf > > > Am 05.03.2010 22:59, schrieb Neal Gafter: >> On Fri, Mar 5, 2010 at 1:47 PM, Ulf Zibis > > wrote: >> >> No response ?? :-( >> >> >> Keith's response is correct. An assertion in a method only occurs >> when the method is executed. An assertion in a constructor only >> occurs when the constructor is called. An assertion in a static >> initializer only occurs when the class is statically initialized. >> Accessing a constant of the class does not initialize the class. So >> there is no bug. >> >> Cheers, >> Neal >> >> >> I've filed a bug: >> >> internal review ID of 1730072 >> >> >> -Ulf >> >> >> >> Am 12.02.2010 15:44, schrieb Ulf Zibis: >> >> Am 12.02.2010 15:06, schrieb Ulf Zibis: >> >> Hi, >> >> in the following example, I have an assert statement in a >> static block of my class. >> >> If accessing the static final constants from another >> class, the static block is not executed. >> This causes the assertions to remain un-proofed, even if >> -ea -esa is set. >> >> Is that correct ? >> >> >> If yes, javac should claim the code as never reached. >> >> >> IMO, assertions should always run, if -ea -esa is set. >> >> -Ulf >> >> >> -Ulf >> >> >> >From - Fri Feb 12 16:25:03 2010 >> X-Account-Key: account2 >> X-UIDL: 5de5c7b81a751aec6aed7ffb66ca9b90 >> X-Mozilla-Status: 0000 >> X-Mozilla-Status2: 00000000 >> X-Mozilla-Keys: >> X-Symantec-TimeoutProtection: 0 >> X-Symantec-TimeoutProtection: 1 >> X-Symantec-TimeoutProtection: 2 >> Return-Path: >> X-Flags: 1001 >> Delivered-To: GMX delivery to ulf.zibis at gmx.de >> >> Received: (qmail invoked by alias); 12 Feb 2010 15:12:59 -0000 >> Received: from brmea-mail-2.Sun.COM >> (EHLO brmea-mail-2.sun.com >> ) [192.18.98.43] >> by mx0.gmx.net (mx002) with SMTP; 12 >> Feb 2010 16:12:59 +0100 >> Received: from fe-amer-09.sun.com >> ([192.18.109.79]) >> by brmea-mail-2.sun.com >> (8.13.6+Sun/8.12.9) with ESMTP id o1CFCw62027512 >> for >; Fri, 12 >> Feb 2010 15:12:58 GMT >> MIME-version: 1.0 >> Content-transfer-encoding: 7BIT >> Content-type: text/plain; CHARSET=US-ASCII; format=flowed >> Received: from conversion-daemon.mail-amer.sun.com >> by >> mail-amer.sun.com >> (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built >> Jul 2 2009)) >> id <0KXQ00800HZH3I00 at mail-amer.sun.com >> > for >> Ulf.Zibis at gmx.de ; Fri, >> 12 Feb 2010 08:12:58 -0700 (MST) >> Received: from [129.150.65.45] ([unknown] [129.150.65.45]) >> by mail-amer.sun.com (Sun Java(tm) >> System Messaging Server 7u2-7.04 64bit >> (built Jul 2 2009)) with ESMTPSA id >> <0KXQ00GTLI9L1V60 at mail-amer.sun.com >> >; Fri, >> 12 Feb 2010 08:12:58 -0700 (MST) >> Date: Fri, 12 Feb 2010 10:12:58 -0500 >> From: Keith McGuigan >> Subject: Re: Assertions in static blocks ? >> In-reply-to: <4B756071.4000104 at gmx.de >> > >> Sender: Keith.McGuigan at Sun.COM >> To: Ulf Zibis > >> Cc: compiler-dev at openjdk.java.net >> , hotspot >> > > >> Message-id: <4B756FFA.9000806 at sun.com >> > >> References: <4B756071.4000104 at gmx.de >> > >> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) >> X-GMX-Antivirus: 0 (no virus found) >> X-GMX-Antispam: 0 (Mail was not recognized as spam); >> Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDmtyzoN37OXMt9GpYHsrWRra7o+psEYuNg/dar >> >> zWRIb1W0k0rd15IZBf9O4nqjKYX9PrVGG/zPEENchmY89mOrfO0W57R8iRtiMheMiqQP1ym7bl2H >> >> PZZzg==V1; >> X-GMX-UID: ylpHc/1fPjlsBVAdATU22s0zMTE2Ncn9 >> >> >> >> Hi Ulf - >> >> Accessing a constant static field in a class does not trigger >> class initialization, so your initializer is probably just >> not being run. >> >> See >> http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19075 >> >> >> -- >> - Keith >> >> Ulf Zibis wrote: >> >> Hi, >> >> in the following example, I have an assert statement in a >> static block of my class. >> >> If accessing the static final constants from another >> class, the static block is not executed. >> This causes the assertions to remain un-proofed, even if >> -ea -esa is set. >> >> Is that correct ? >> >> IMO, assertions should always run, if -ea -esa is set. >> >> -Ulf >> >> >> >> package sun.nio.cs.ext; >> >> import static sun.nio.cs.CharsetMapping.*; >> >> /** >> * >> * @author Ulf Zibis, Cologne CoSoCo.de >> */ >> class EUC_TWMapping3 extends EUC_TWMapping { >> static final short PL0_5_B2C_RANGE = 0x2300; // plane >> 0, 5 b2c range >> static final short PLANE_B2C_RANGE = 0x1f00; // plane >> 2..4, 6..15 b2c range >> >> // TODO: file bug: static block should run, if assertions >> are enabled. >> static { >> // assert plane offsets and content >> for (int p=0, range, offset=0; p> range = p % 4 == 0 ? PL0_5_B2C_RANGE : >> PLANE_B2C_RANGE; >> for (int i=range; i> assert b2c[p].charAt(i) == >> UNMAPPABLE_DECODING; >> // static block should run, if assertions are enabled. >> For test uncomment following line >> // System.out.printf("offset: %d, range: %d, >> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >> assert (offset += range) <= >> Character.MAX_VALUE + 1; >> } >> } >> >> // WORKAROUND: >> // static int offset = 0; // assert from calling >> context to force static block to process >> // static { >> // // assert plane offsets and content >> // for (int p=0, range; p> // range = p % 4 == 0 ? PL0_5_B2C_RANGE : >> PLANE_B2C_RANGE; >> // for (int i=range; i> // assert b2c[p].charAt(i) == >> UNMAPPABLE_DECODING; >> //// static block should run, if assertions are enabled. >> For test uncomment following line >> //// System.out.printf("offset: %d, range: %d, >> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >> // assert (offset += range) <= >> Character.MAX_VALUE + 1; >> // } >> //// static block should run, if assertions are enabled. >> For test uncomment following line >> //// assert false; >> // } >> } >> >> >> package sun.nio.cs.ext; >> >> /** >> * >> * @author Ulf Zibis, Cologne CoSoCo.de >> */ >> public class AssertTest { >> >> public static void main(String... args) { >> // static block in EUC_TWMapping3 should run, if >> assertions are enabled. >> System.out.println(EUC_TWMapping3.PLANE_B2C_RANGE); >> // WORKAROUND: For test uncomment following line >> // assert EUC_TWMapping3.offset > 0; // force >> assertion, TODO: JDK bug ? >> } >> } >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100305/7489f8e6/attachment.html From lists at laerad.com Fri Mar 5 15:34:19 2010 From: lists at laerad.com (Benedict Elliott Smith) Date: Fri, 5 Mar 2010 23:34:19 +0000 Subject: Assertions in static blocks ? In-Reply-To: <4B918EE0.7010709@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> Message-ID: <51a29d951003051534m7799de34je538a9cf2736785e@mail.gmail.com> It's not generally possible to determine if a class initializer will ever be run. It would be possible to determine that, if a class were declared with default (package) level protection and was never referenced by another class in the package, that the class was not used (so long as the program did not violate the protection via reflection); but this is the best that could be achieved (there is an argument to be made for javac to complain in this case, as it will in the case of unused private classes, however I am not certain it is necessary), however I do not think this is what you are suggesting. It would be possible, if the class were declared with default protection, and no class in the package referenced anything within it other than constant fields, to determine that the initialiser was never executed, I suppose. I'm not a developer of javac but I'm not convinced that it is a sufficiently useful boundary case to warrant the burden of every execution of javac in the world calculating it. Probably the increased global power usage as a result of this would raise the sea level another micrometer or two for very little benefit in my mind! On 5 March 2010 23:08, Ulf Zibis wrote: > Neal, Keith, thanks for your answer. > > ... but shouldn't javac claim, that there the code in the static block will > be *never reached*, if there is no trigger to run it? > > -Ulf > > > Am 05.03.2010 22:59, schrieb Neal Gafter: > > On Fri, Mar 5, 2010 at 1:47 PM, Ulf Zibis wrote: > >> No response ?? :-( >> > > Keith's response is correct. An assertion in a method only occurs when the > method is executed. An assertion in a constructor only occurs when the > constructor is called. An assertion in a static initializer only occurs > when the class is statically initialized. Accessing a constant of the class > does not initialize the class. So there is no bug. > > Cheers, > Neal > > >> I've filed a bug: >> >> internal review ID of 1730072 >> >> >> -Ulf >> >> >> >> Am 12.02.2010 15:44, schrieb Ulf Zibis: >> >>> Am 12.02.2010 15:06, schrieb Ulf Zibis: >>> >>>> Hi, >>>> >>>> in the following example, I have an assert statement in a static block >>>> of my class. >>>> >>>> If accessing the static final constants from another class, the static >>>> block is not executed. >>>> This causes the assertions to remain un-proofed, even if -ea -esa is >>>> set. >>>> >>>> Is that correct ? >>>> >>> >>> If yes, javac should claim the code as never reached. >>> >>> >>>> IMO, assertions should always run, if -ea -esa is set. >>>> >>>> -Ulf >>>> >>>> >>> -Ulf >>> >>> >>> >From - Fri Feb 12 16:25:03 2010 >>> X-Account-Key: account2 >>> X-UIDL: 5de5c7b81a751aec6aed7ffb66ca9b90 >>> X-Mozilla-Status: 0000 >>> X-Mozilla-Status2: 00000000 >>> X-Mozilla-Keys: >>> X-Symantec-TimeoutProtection: 0 >>> X-Symantec-TimeoutProtection: 1 >>> X-Symantec-TimeoutProtection: 2 >>> Return-Path: >>> X-Flags: 1001 >>> Delivered-To: GMX delivery to ulf.zibis at gmx.de >>> Received: (qmail invoked by alias); 12 Feb 2010 15:12:59 -0000 >>> Received: from brmea-mail-2.Sun.COM (EHLO brmea-mail-2.sun.com) >>> [192.18.98.43] >>> by mx0.gmx.net (mx002) with SMTP; 12 Feb 2010 16:12:59 +0100 >>> Received: from fe-amer-09.sun.com ([192.18.109.79]) >>> by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id >>> o1CFCw62027512 >>> for ; Fri, 12 Feb 2010 15:12:58 GMT >>> MIME-version: 1.0 >>> Content-transfer-encoding: 7BIT >>> Content-type: text/plain; CHARSET=US-ASCII; format=flowed >>> Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com >>> (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) >>> id <0KXQ00800HZH3I00 at mail-amer.sun.com> for Ulf.Zibis at gmx.de; Fri, >>> 12 Feb 2010 08:12:58 -0700 (MST) >>> Received: from [129.150.65.45] ([unknown] [129.150.65.45]) >>> by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 >>> 64bit >>> (built Jul 2 2009)) with ESMTPSA id <0KXQ00GTLI9L1V60 at mail-amer.sun.com>; >>> Fri, >>> 12 Feb 2010 08:12:58 -0700 (MST) >>> Date: Fri, 12 Feb 2010 10:12:58 -0500 >>> From: Keith McGuigan >>> Subject: Re: Assertions in static blocks ? >>> In-reply-to: <4B756071.4000104 at gmx.de> >>> Sender: Keith.McGuigan at Sun.COM >>> To: Ulf Zibis >>> Cc: compiler-dev at openjdk.java.net, hotspot >> > >>> Message-id: <4B756FFA.9000806 at sun.com> >>> References: <4B756071.4000104 at gmx.de> >>> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) >>> X-GMX-Antivirus: 0 (no virus found) >>> X-GMX-Antispam: 0 (Mail was not recognized as spam); >>> Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDmtyzoN37OXMt9GpYHsrWRra7o+psEYuNg/dar >>> >>> zWRIb1W0k0rd15IZBf9O4nqjKYX9PrVGG/zPEENchmY89mOrfO0W57R8iRtiMheMiqQP1ym7bl2H >>> >>> PZZzg==V1; >>> X-GMX-UID: ylpHc/1fPjlsBVAdATU22s0zMTE2Ncn9 >>> >>> >>> >>> Hi Ulf - >>> >>> Accessing a constant static field in a class does not trigger class >>> initialization, so your initializer is probably just not being run. >>> >>> See >>> http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19075 >>> >>> -- >>> - Keith >>> >>> Ulf Zibis wrote: >>> >>>> Hi, >>>> >>>> in the following example, I have an assert statement in a static block >>>> of my class. >>>> >>>> If accessing the static final constants from another class, the static >>>> block is not executed. >>>> This causes the assertions to remain un-proofed, even if -ea -esa is >>>> set. >>>> >>>> Is that correct ? >>>> >>>> IMO, assertions should always run, if -ea -esa is set. >>>> >>>> -Ulf >>>> >>>> >>>> >>>> package sun.nio.cs.ext; >>>> >>>> import static sun.nio.cs.CharsetMapping.*; >>>> >>>> /** >>>> * >>>> * @author Ulf Zibis, Cologne CoSoCo.de >>>> */ >>>> class EUC_TWMapping3 extends EUC_TWMapping { >>>> static final short PL0_5_B2C_RANGE = 0x2300; // plane 0, 5 b2c range >>>> static final short PLANE_B2C_RANGE = 0x1f00; // plane 2..4, 6..15 b2c >>>> range >>>> >>>> // TODO: file bug: static block should run, if assertions are enabled. >>>> static { >>>> // assert plane offsets and content >>>> for (int p=0, range, offset=0; p>>> range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >>>> for (int i=range; i>>> assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >>>> // static block should run, if assertions are enabled. For test >>>> uncomment following line >>>> // System.out.printf("offset: %d, range: %d, b2c[p].length(): >>>> %d%n", offset, range, b2c[p].length()); >>>> assert (offset += range) <= Character.MAX_VALUE + 1; >>>> } >>>> } >>>> >>>> // WORKAROUND: >>>> // static int offset = 0; // assert from calling context to force >>>> static block to process >>>> // static { >>>> // // assert plane offsets and content >>>> // for (int p=0, range; p>>> // range = p % 4 == 0 ? PL0_5_B2C_RANGE : PLANE_B2C_RANGE; >>>> // for (int i=range; i>>> // assert b2c[p].charAt(i) == UNMAPPABLE_DECODING; >>>> //// static block should run, if assertions are enabled. For test >>>> uncomment following line >>>> //// System.out.printf("offset: %d, range: %d, >>>> b2c[p].length(): %d%n", offset, range, b2c[p].length()); >>>> // assert (offset += range) <= Character.MAX_VALUE + 1; >>>> // } >>>> //// static block should run, if assertions are enabled. For test >>>> uncomment following line >>>> //// assert false; >>>> // } >>>> } >>>> >>>> >>>> package sun.nio.cs.ext; >>>> >>>> /** >>>> * >>>> * @author Ulf Zibis, Cologne CoSoCo.de >>>> */ >>>> public class AssertTest { >>>> >>>> public static void main(String... args) { >>>> // static block in EUC_TWMapping3 should run, if assertions are enabled. >>>> System.out.println(EUC_TWMapping3.PLANE_B2C_RANGE); >>>> // WORKAROUND: For test uncomment following line >>>> // assert EUC_TWMapping3.offset > 0; // force assertion, TODO: >>>> JDK bug ? >>>> } >>>> } >>>> >>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100305/93d13a4d/attachment-0001.html From Ulf.Zibis at gmx.de Sat Mar 6 03:35:03 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 06 Mar 2010 12:35:03 +0100 Subject: Assertions in static blocks ? In-Reply-To: <4B91AFD2.8040503@sun.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> Message-ID: <4B923DE7.403@gmx.de> Am 06.03.2010 02:28, schrieb Keith McGuigan: > Ulf Zibis wrote: >> Neal, Keith, thanks for your answer. >> >> ... but shouldn't javac claim, that there the code in the static >> block will be *never reached*, if there is no trigger to run it? > > Not really. That would be like claiming that the code in a method > will never be reached if no one calls the method. javac can't know > that you're not going to take that class and deploy it somewhere else > with other code that will end up calling the method (or initializing > the class, etc.). But javac can know about the risk, because running Class.forName() is "not very common", especially if there is nothing but constants in that class. The minimum, javac could do is to throw a warning. On the other hand, javac throws errors, even if the stated problem never occurs: char c1 = 12345; char c2 = c1 % 100; would result in ERROR: "possible loss of precision", but c1 *= 12345; compiles without problem. Do you know, if following static initializer will be guaranteed to run, when accessing the static value? : class EUC_TWMapping3 extends EUC_TWMapping { static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range static { PL0_5_B2C_RANGE = 0x2300; // initialized here to force the assertions! PLANE_B2C_RANGE = 0x1f00; // " " " // assert by values from EUC_TWMapping assert PL0_5_B2C_RANGE >= b2c.length; assert PLANE_B2C_RANGE <= b2c.length; } } -Ulf From Ulf.Zibis at gmx.de Sat Mar 6 03:44:43 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 06 Mar 2010 12:44:43 +0100 Subject: Assertions in static blocks ? In-Reply-To: <51a29d951003051533v2750b564pbd99e7c590af95d7@mail.gmail.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <51a29d951003051533v2750b564pbd99e7c590af95d7@mail.gmail.com> Message-ID: <4B92402B.8080403@gmx.de> Am 06.03.2010 00:33, schrieb Benedict Elliott Smith: > It's not /generally/ possible to determine if a class initializer will > ever be run. > > It would be possible to determine that, if a class were declared with > default (package) level protection and was never referenced by another > class in the package, that the class was not used (/so long as the > program did not violate the protection via reflection)/; but this is > the best that could be achieved (there is an argument to be made for > javac to complain in this case, as it will in the case of unused > private classes, however I am not certain it is necessary), however I > do not think this is what you are suggesting. > > It would be possible, if the class were declared with default > protection, and no class in the package referenced anything within it > other than constant fields, to determine that the initialiser was > never executed, I suppose. My class *is* package private, but I can't see how it should help. ... and currently it doesn't help to make the static initializer running. > I'm not a developer of javac but I'm not convinced that it is a > sufficiently useful boundary case to warrant the burden of every > execution of javac in the world calculating it. Probably > the increased global power usage as a result of this would raise the > sea level another micrometer or two for very little benefit in my mind! I like to think about power usage. That's the reason I'm working on EUC_TW charset making it faster and consuming less memory. Checking practically never reached static blocks seems to be nothing than working on a system using EUC_TW charset. -Ulf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100306/5c782d39/attachment.html From schlosna at gmail.com Sat Mar 6 11:55:33 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Sat, 6 Mar 2010 14:55:33 -0500 Subject: Assertions in static blocks ? In-Reply-To: <4B923DE7.403@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> Message-ID: <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> Ulf, The behavior you're encountering is consistent with JLS ?4.12.4 [1] which states: We call a variable, of primitive type or type String, that is final and initialized with a compile-time constant expression (?15.28) a constant variable. Whether a variable is a constant variable or not may have implications with respect to class initialization (?12.4.1), binary compatibility (?13.1, ?13.4.9) and definite assignment (?16). Later in JLS ?13.1 [2] it states: References to fields that are constant variables (?4.12.4) are resolved at compile time to the constant value that is denoted. No reference to such a constant field should be present in the code in a binary file (except in the class or interface containing the constant field, which will have code to initialize it), and such constant fields must always appear to have been initialized; the default initial value for the type of such a field must never be observed. See ?13.4.8 for a discussion. Check out Java Puzzler 93: Class Warfare [3] which gives an example of this and how it impacts binary compatibility. Josh and Neal also covered this in the 2009 JavaOne Puzzler talk, see #7 "When Words Collide" [4]. Based on that, anywhere that PL0_5_B2C_RANGE or PLANE_B2C_RANGE are used the actual values will be inlined into the referencing class file at compile time as "sipush 8960" or "sipush 7936" respectively, and therefore do not reference the class EUC_TWMapping3 or cause it to be initialized. If you do want to ensure the assertions are run when at class initialization, I'd recommend something like the following which will ensure that the value is not inlined at compile time: class EUC_TWMapping3 extends EUC_TWMapping { static final short PL0_5_B2C_RANGE = planeZeroFiveB2CRange(); // plane 0, 5 b2c range static final short PLANE_B2C_RANGE = planeB2CRange(); // plane 2..4, 6..15 b2c range private static final short planeZeroFiveB2CRange() { short range = 0x2300; // plane 0, 5 b2c range assert range >= b2c.length; // assert by values from EUC_TWMapping return range; } private static final short planeB2CRange() { short range = 0x1f00; // plane 2..4, 6..15 b2c range assert range <= b2c.length; // assert by values from EUC_TWMapping return range; } } [1]: http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.4 [2]: http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.1 [3]: http://www.javapuzzlers.com [4]: http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5186&yr=2009&track=javase - Dave On Sat, Mar 6, 2010 at 6:35 AM, Ulf Zibis wrote: > Am 06.03.2010 02:28, schrieb Keith McGuigan: >> >> Ulf Zibis wrote: >>> >>> Neal, Keith, thanks for your answer. >>> >>> ... but shouldn't javac claim, that there the code in the static block >>> will be *never reached*, if there is no trigger to run it? >> >> Not really. That would be like claiming that the code in a method will >> never be reached if no one calls the method. javac can't know that you're >> not going to take that class and deploy it somewhere else with other code >> that will end up calling the method (or initializing the class, etc.). > > But javac can know about the risk, because running Class.forName() is "not > very common", especially if there is nothing but constants in that class. > The minimum, javac could do is to throw a warning. > > On the other hand, javac throws errors, even if the stated problem never > occurs: > char c1 = 12345; > char c2 = c1 % 100; > would result in ERROR: "possible loss of precision", but > c1 *= 12345; > compiles without problem. > > Do you know, if following static initializer will be guaranteed to run, when > accessing the static value? : > > class EUC_TWMapping3 extends EUC_TWMapping { > static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range > static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range > static { > PL0_5_B2C_RANGE = 0x2300; // initialized here to force the > assertions! > PLANE_B2C_RANGE = 0x1f00; // " " " > // assert by values from EUC_TWMapping > assert PL0_5_B2C_RANGE >= b2c.length; > assert PLANE_B2C_RANGE <= b2c.length; > } > } > > -Ulf > > > > From David.Holmes at Sun.COM Sat Mar 6 16:34:26 2010 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Sun, 07 Mar 2010 10:34:26 +1000 Subject: Assertions in static blocks ? In-Reply-To: <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> Message-ID: <4B92F492.6000305@sun.com> David, Ulf, Note that in Ulf's example: class EUC_TWMapping3 extends EUC_TWMapping { static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range static { PL0_5_B2C_RANGE = 0x2300; // initialized here to force the assertions! PLANE_B2C_RANGE = 0x1f00; // " " " // assert by values from EUC_TWMapping assert PL0_5_B2C_RANGE >= b2c.length; assert PLANE_B2C_RANGE <= b2c.length; } } the fields are _NOT_ initialized with compile-time constant expressions and so access to them will be via a getstatic bytecode which will result in class initialization. David Holmes ------------ David Schlosnagle said the following on 03/07/10 05:55: > Ulf, > > The behavior you're encountering is consistent with JLS ?4.12.4 [1] which > states: > We call a variable, of primitive type or type String, that is final and > initialized with a compile-time constant expression (?15.28) a constant > variable. Whether a variable is a constant variable or not may have > implications with respect to class initialization (?12.4.1), binary > compatibility (?13.1, ?13.4.9) and definite assignment (?16). > > Later in JLS ?13.1 [2] it states: > References to fields that are constant variables (?4.12.4) are resolved at > compile time to the constant value that is denoted. No reference to such a > constant field should be present in the code in a binary file (except in > the class or interface containing the constant field, which will have code > to initialize it), and such constant fields must always appear to have been > initialized; the default initial value for the type of such a field must > never be observed. See ?13.4.8 for a discussion. > > Check out Java Puzzler 93: Class Warfare [3] which gives an example of this and > how it impacts binary compatibility. Josh and Neal also covered this in the > 2009 JavaOne Puzzler talk, see #7 "When Words Collide" [4]. > > Based on that, anywhere that PL0_5_B2C_RANGE or PLANE_B2C_RANGE are used the > actual values will be inlined into the referencing class file at compile time > as "sipush 8960" or "sipush 7936" respectively, and therefore do not reference > the class EUC_TWMapping3 or cause it to be initialized. > > If you do want to ensure the assertions are run when at class initialization, > I'd recommend something like the following which will ensure that the value is > not inlined at compile time: > > class EUC_TWMapping3 extends EUC_TWMapping { > static final short PL0_5_B2C_RANGE = planeZeroFiveB2CRange(); // > plane 0, 5 b2c range > static final short PLANE_B2C_RANGE = planeB2CRange(); // plane > 2..4, 6..15 b2c range > > private static final short planeZeroFiveB2CRange() { > short range = 0x2300; // plane 0, 5 b2c range > assert range >= b2c.length; // assert by values from EUC_TWMapping > return range; > } > > private static final short planeB2CRange() { > short range = 0x1f00; // plane 2..4, 6..15 b2c range > assert range <= b2c.length; // assert by values from EUC_TWMapping > return range; > } > } > > [1]: http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.4 > [2]: http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.1 > [3]: http://www.javapuzzlers.com > [4]: http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5186&yr=2009&track=javase > > - Dave > > > > On Sat, Mar 6, 2010 at 6:35 AM, Ulf Zibis wrote: >> Am 06.03.2010 02:28, schrieb Keith McGuigan: >>> Ulf Zibis wrote: >>>> Neal, Keith, thanks for your answer. >>>> >>>> ... but shouldn't javac claim, that there the code in the static block >>>> will be *never reached*, if there is no trigger to run it? >>> Not really. That would be like claiming that the code in a method will >>> never be reached if no one calls the method. javac can't know that you're >>> not going to take that class and deploy it somewhere else with other code >>> that will end up calling the method (or initializing the class, etc.). >> But javac can know about the risk, because running Class.forName() is "not >> very common", especially if there is nothing but constants in that class. >> The minimum, javac could do is to throw a warning. >> >> On the other hand, javac throws errors, even if the stated problem never >> occurs: >> char c1 = 12345; >> char c2 = c1 % 100; >> would result in ERROR: "possible loss of precision", but >> c1 *= 12345; >> compiles without problem. >> >> Do you know, if following static initializer will be guaranteed to run, when >> accessing the static value? : >> >> class EUC_TWMapping3 extends EUC_TWMapping { >> static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range >> static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range >> static { >> PL0_5_B2C_RANGE = 0x2300; // initialized here to force the >> assertions! >> PLANE_B2C_RANGE = 0x1f00; // " " " >> // assert by values from EUC_TWMapping >> assert PL0_5_B2C_RANGE >= b2c.length; >> assert PLANE_B2C_RANGE <= b2c.length; >> } >> } >> >> -Ulf >> >> >> >> From schlosna at gmail.com Sat Mar 6 17:39:28 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Sat, 6 Mar 2010 20:39:28 -0500 Subject: Assertions in static blocks ? In-Reply-To: <4B92F492.6000305@sun.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> Message-ID: <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> David, You're correct, Ulf's example code from earlier today where the actual value is initialized in a static initializer block does use getstatic and would trigger the EUC_TWMapping3 class's initialization and provides the desired functionality. Sorry, I meant to clarify the answer to Ulf's original email from February 12 "If accessing the static final constants from another class, the static block is not executed." showing this isn't a bug. In that email's code they were compile time constants, and the JLS justifies why the static block wasn't executed. This can lead to surprising behavior if you're not aware of it which is one reason I prefer extracting any complex initialization behavior into a separate method when possible to make it more explicit. - Dave On Fri, Feb 12, 2010 at 9:06 AM, Ulf Zibis wrote: > If accessing the static final constants from another class, the static block > is not executed. > This causes the assertions to remain un-proofed, even if -ea -esa is set. > > Is that correct ? ...snip... > class EUC_TWMapping3 extends EUC_TWMapping { > static final short PL0_5_B2C_RANGE = 0x2300; // plane 0, 5 b2c range > static final short PLANE_B2C_RANGE = 0x1f00; // plane 2..4, 6..15 b2c > range On Sat, Mar 6, 2010 at 7:34 PM, David Holmes - Sun Microsystems wrote: > David, Ulf, > > Note that in Ulf's example: > > class EUC_TWMapping3 extends EUC_TWMapping { > ? ?static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range > ? ?static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range > ? ?static { > ? ? ? ?PL0_5_B2C_RANGE = 0x2300; // initialized here to force the > assertions! > ? ? ? ?PLANE_B2C_RANGE = 0x1f00; // ? ? ?" ? ? ? ? ? ? " ? ? ? ? ? ?" > ? ? ? ?// assert by values from EUC_TWMapping > ? ? ? ?assert PL0_5_B2C_RANGE >= b2c.length; > ? ? ? ?assert PLANE_B2C_RANGE <= b2c.length; > ? ?} > } > > the fields are _NOT_ initialized with compile-time constant expressions and > so access to them will be via a getstatic bytecode which will result in > class initialization. > > David Holmes > ------------ > > David Schlosnagle said the following on 03/07/10 05:55: >> >> Ulf, >> >> The behavior you're encountering is consistent with JLS ?4.12.4 [1] which >> states: >> ? ?We call a variable, of primitive type or type String, that is final and >> ? ?initialized with a compile-time constant expression (?15.28) a constant >> ? ?variable. Whether a variable is a constant variable or not may have >> ? ?implications with respect to class initialization (?12.4.1), binary >> ? ?compatibility (?13.1, ?13.4.9) and definite assignment (?16). >> >> Later in JLS ?13.1 [2] it states: >> ? ?References to fields that are constant variables (?4.12.4) ?are >> resolved at >> ? ?compile time to the constant value that is denoted. No reference to >> such a >> ? ?constant field should be present in the code in a binary file (except >> in >> ? ?the class or interface containing the constant field, which will have >> code >> ? ?to initialize it), and such constant fields must always appear to have >> been >> ? ?initialized; the default initial value for the type of such a field >> must >> ? ?never be observed. See ?13.4.8 for a discussion. >> >> Check out Java Puzzler 93: Class Warfare [3] which gives an example of >> this and >> how it impacts binary compatibility. Josh and Neal also covered this in >> the >> 2009 JavaOne Puzzler talk, see #7 "When Words Collide" [4]. >> >> Based on that, anywhere that PL0_5_B2C_RANGE or PLANE_B2C_RANGE are used >> the >> actual values will be inlined into the referencing class file at compile >> time >> as "sipush ?8960" or "sipush 7936" respectively, and therefore do not >> reference >> the class EUC_TWMapping3 or cause it to be initialized. >> >> If you do want to ensure the assertions are run when at class >> initialization, >> I'd recommend something like the following which will ensure that the >> value is >> not inlined at compile time: >> >> class EUC_TWMapping3 extends EUC_TWMapping { >> ? ?static final short PL0_5_B2C_RANGE = planeZeroFiveB2CRange(); // >> plane 0, 5 b2c range >> ? ?static final short PLANE_B2C_RANGE = planeB2CRange(); // plane >> 2..4, 6..15 b2c range >> >> ? ?private static final short planeZeroFiveB2CRange() { >> ? ? ? ?short range = 0x2300; // plane 0, 5 b2c range >> ? ? ? ?assert range >= b2c.length; // assert by values from EUC_TWMapping >> ? ? ? ?return range; >> ? ?} >> >> ? ?private static final short planeB2CRange() { >> ? ? ? ?short range = 0x1f00; // plane 2..4, 6..15 b2c range >> ? ? ? ?assert range <= b2c.length; // assert by values from EUC_TWMapping >> ? ? ? ?return range; >> ? ?} >> } >> >> [1]: >> http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.4 >> [2]: >> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#13.1 >> [3]: http://www.javapuzzlers.com >> [4]: >> http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5186&yr=2009&track=javase >> >> - Dave >> >> >> >> On Sat, Mar 6, 2010 at 6:35 AM, Ulf Zibis wrote: >>> >>> Am 06.03.2010 02:28, schrieb Keith McGuigan: >>>> >>>> Ulf Zibis wrote: >>>>> >>>>> Neal, Keith, thanks for your answer. >>>>> >>>>> ... but shouldn't javac claim, that there the code in the static block >>>>> will be *never reached*, if there is no trigger to run it? >>>> >>>> Not really. ?That would be like claiming that the code in a method will >>>> never be reached if no one calls the method. ?javac can't know that >>>> you're >>>> not going to take that class and deploy it somewhere else with other >>>> code >>>> that will end up calling the method (or initializing the class, etc.). >>> >>> But javac can know about the risk, because running Class.forName() is >>> "not >>> very common", especially if there is nothing but constants in that class. >>> The minimum, javac could do is to throw a warning. >>> >>> On the other hand, javac throws errors, even if the stated problem never >>> occurs: >>> ? ? ? ? ? char c1 = 12345; >>> ? ? ? ? ? char c2 = c1 % 100; >>> would result in ERROR: "possible loss of precision", but >>> ? ? ? ? ? c1 *= 12345; >>> compiles without problem. >>> >>> Do you know, if following static initializer will be guaranteed to run, >>> when >>> accessing the static value? : >>> >>> class EUC_TWMapping3 extends EUC_TWMapping { >>> ? static final short PL0_5_B2C_RANGE; // plane 0, 5 b2c range >>> ? static final short PLANE_B2C_RANGE; // plane 2..4, 6..15 b2c range >>> ? static { >>> ? ? ? PL0_5_B2C_RANGE = 0x2300; // initialized here to force the >>> assertions! >>> ? ? ? PLANE_B2C_RANGE = 0x1f00; // ? ? ?" ? ? ? ? ? ? " ? ? ? ? ? ?" >>> ? ? ? // assert by values from EUC_TWMapping >>> ? ? ? assert PL0_5_B2C_RANGE >= b2c.length; >>> ? ? ? assert PLANE_B2C_RANGE <= b2c.length; >>> ? } >>> } >>> >>> -Ulf >>> >>> >>> >>> > From Ulf.Zibis at gmx.de Sun Mar 7 07:40:43 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sun, 07 Mar 2010 16:40:43 +0100 Subject: Assertions in static blocks ? In-Reply-To: <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> Message-ID: <4B93C8FB.4090709@gmx.de> Am 07.03.2010 02:39, schrieb David Schlosnagle: > David, > > You're correct, Ulf's example code from earlier today where the actual > value is initialized in a static initializer block does use getstatic > and would trigger the EUC_TWMapping3 class's initialization and > provides the desired functionality. > > Sorry, I meant to clarify the answer to Ulf's original email from > February 12 "If accessing the static final constants from another > class, the static block is not executed." showing this isn't a bug. In > that email's code they were compile time constants, and the JLS > justifies why the static block wasn't executed. This can lead to > surprising behavior if you're not aware of it which is one reason I > prefer extracting any complex initialization behavior into a separate > method when possible to make it more explicit. > Aside: I prefer short and fast code, and would put the "make it more explicit" in a comment. ;-) In contrast to Keith and Neal, I think, we agree, that this "behaviour is surprising", so I would vote at least for a *warning* from javac side. -Ulf From David.Holmes at Sun.COM Sun Mar 7 14:20:32 2010 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 08 Mar 2010 08:20:32 +1000 Subject: Assertions in static blocks ? In-Reply-To: <4B93C8FB.4090709@gmx.de> References: <4B756071.4000104@gmx.de> <4B756945.1090600@gmx.de> <4B917C05.3020309@gmx.de> <15e8b9d21003051359g69bef477k6160fdc75d6bc20e@mail.gmail.com> <4B918EE0.7010709@gmx.de> <4B91AFD2.8040503@sun.com> <4B923DE7.403@gmx.de> <9146341c1003061155u3fe5457bida8bd6de40c7c311@mail.gmail.com> <4B92F492.6000305@sun.com> <9146341c1003061739r72dd15afgee7a54d02fbf1f42@mail.gmail.com> <4B93C8FB.4090709@gmx.de> Message-ID: <4B9426B0.1070308@sun.com> Ulf Zibis said the following on 03/08/10 01:40: > In contrast to Keith and Neal, I think, we agree, that this "behaviour > is surprising", so I would vote at least for a *warning* from javac side. I'm with Keith and Neal, this is all "working as designed". How can javac in general know whether or not a class will be initialized. A static initializer is no different to a method or constructor in that regard: none of them are ever flagged as unreachable because that can't be determined a-priori by javac. At the absolute most I can concede that javac might issue a warning if a class consisted only of constant field declarations and had a static initializer, as no use of the fields would lead to initialization. But even then I don't think this is worth the effort. Regards, David Holmes From Christian.Thalinger at Sun.COM Mon Mar 8 01:02:36 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 08 Mar 2010 10:02:36 +0100 Subject: Question on TemplateTable::prepare_invoke In-Reply-To: <1267648431.23672.22.camel@witty-114b.unl.edu> References: <1267646996.5285.9.camel@macbook> <1267648431.23672.22.camel@witty-114b.unl.edu> Message-ID: <1268038956.27679.10.camel@macbook> On Wed, 2010-03-03 at 14:33 -0600, Peng Du wrote: > Hi, Tom and Christian > > You're right. The call indeed trashs some regs because pusha+popa solved > the problem. This seems a little brute-force though. Do you have a good > way to trace down which regs are trashed? Well, this is nothing you want to put in a production VM, right? So I wouldn't care too much. -- Christian From andrey.petrusenko at sun.com Mon Mar 8 09:14:58 2010 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Mon, 08 Mar 2010 17:14:58 +0000 Subject: hg: jdk7/hotspot/hotspot: 6910182: CMS: assert(_cursor[j] == _survivor_plab_array[j].end(), "Ctl pt invariant") Message-ID: <20100308171501.E94F644301@hg.openjdk.java.net> Changeset: d47555d7aca8 Author: jmasa Date: 2010-03-03 08:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d47555d7aca8 6910182: CMS: assert(_cursor[j] == _survivor_plab_array[j].end(),"Ctl pt invariant") Summary: Calculation of the slicing of survivor spaces for MT was incorrect. Reviewed-by: ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp From john.coomes at sun.com Tue Mar 9 06:05:17 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 14:05:17 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b85 for changeset cf26288a114b Message-ID: <20100309140518.6294844438@hg.openjdk.java.net> Changeset: 3ddf90b39176 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/3ddf90b39176 Added tag jdk7-b85 for changeset cf26288a114b ! .hgtags From john.coomes at sun.com Tue Mar 9 06:05:23 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 14:05:23 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b85 for changeset c67a9df7bc0c Message-ID: <20100309140526.87FB04443A@hg.openjdk.java.net> Changeset: 6253e28826d1 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/6253e28826d1 Added tag jdk7-b85 for changeset c67a9df7bc0c ! .hgtags From john.coomes at sun.com Tue Mar 9 06:10:05 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 14:10:05 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b85 for changeset 6c0ccabb430d Message-ID: <20100309141006.1AA164443C@hg.openjdk.java.net> Changeset: 81c0f115bbe5 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/81c0f115bbe5 Added tag jdk7-b85 for changeset 6c0ccabb430d ! .hgtags From john.coomes at sun.com Tue Mar 9 06:10:11 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 14:10:11 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b85 for changeset 8424512588ff Message-ID: <20100309141011.B1CD84443D@hg.openjdk.java.net> Changeset: 512b0e924a5a Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/512b0e924a5a Added tag jdk7-b85 for changeset 8424512588ff ! .hgtags From john.coomes at sun.com Tue Mar 9 06:11:01 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 14:11:01 +0000 Subject: hg: jdk7/hotspot/jdk: 13 new changesets Message-ID: <20100309141533.16A5144440@hg.openjdk.java.net> Changeset: 2ba381560071 Author: dcherepanov Date: 2010-02-12 19:58 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2ba381560071 6705345: Enable multiple file selection in AWT FileDialog Reviewed-by: art, anthony, alexp ! src/share/classes/java/awt/FileDialog.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_FileDialog.h + test/java/awt/FileDialog/MultipleMode/MultipleMode.html + test/java/awt/FileDialog/MultipleMode/MultipleMode.java Changeset: d6d2de6ee2d1 Author: lana Date: 2010-02-19 15:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d6d2de6ee2d1 Merge Changeset: 83c34a6b1458 Author: mchung Date: 2010-02-08 23:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/83c34a6b1458 6924497: HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE Summary: Check if the element in the flags array is non-null to filter unsupported flags Reviewed-by: dcubed ! src/share/classes/sun/management/Flag.java ! src/share/native/sun/management/Flag.c Changeset: ec438f2b6886 Author: chegar Date: 2010-02-10 13:23 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ec438f2b6886 6693244: Java Web Start app fails on 6u10 beta w/ AssertionError in AuthenticationInfo.requestCompleted Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! test/ProblemList.txt ! test/java/net/Authenticator/B4769350.java Changeset: 784e52734b8d Author: mchung Date: 2010-02-10 17:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/784e52734b8d 6915413: Module build: building of specified jdk components instead of all Summary: Define new SUBDIRS_* variables for specifying components for one group Reviewed-by: ohair ! make/Makefile ! make/com/Makefile ! make/com/sun/Makefile ! make/com/sun/demo/Makefile ! make/com/sun/demo/jvmti/Makefile ! make/com/sun/inputmethods/Makefile ! make/com/sun/java/Makefile ! make/com/sun/java/browser/Makefile ! make/com/sun/jmx/Makefile ! make/com/sun/jndi/Makefile ! make/com/sun/jndi/rmi/Makefile ! make/com/sun/nio/Makefile ! make/com/sun/org/Makefile ! make/com/sun/org/apache/Makefile ! make/com/sun/security/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tracing/Makefile ! make/common/Defs.gmk ! make/common/Sanity.gmk + make/common/Subdirs.gmk ! make/common/shared/Sanity.gmk ! make/java/Makefile ! make/java/hpi/Makefile ! make/java/java/Makefile ! make/java/java/genlocales.gmk ! make/java/main/Makefile ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile + make/java/nio/mxbean/Makefile ! make/java/redist/Makefile - make/java/text/FILES_java.gmk ! make/java/text/Makefile + make/java/text/base/FILES_java.gmk + make/java/text/base/Makefile + make/java/text/bidi/Makefile ! make/javax/Makefile ! make/javax/rmi/Makefile ! make/javax/sound/Makefile ! make/javax/swing/Makefile ! make/jpda/Makefile ! make/jpda/transport/Makefile ! make/mkdemo/Makefile ! make/mkdemo/applets/Makefile ! make/mkdemo/jfc/Makefile ! make/mkdemo/jni/Makefile ! make/mkdemo/jvmti/Makefile ! make/mkdemo/management/Makefile ! make/mkdemo/scripting/Makefile ! make/mksample/Makefile ! make/mksample/jmx/Makefile ! make/mksample/nio/Makefile ! make/mksample/scripting/Makefile ! make/mksample/webservices/Makefile ! make/org/Makefile ! make/org/ietf/Makefile ! make/sun/Makefile ! make/sun/cmm/Makefile ! make/sun/image/Makefile ! make/sun/management/Makefile ! make/sun/net/Makefile ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/Makefile ! make/sun/nio/Makefile ! make/sun/org/Makefile ! make/sun/org/mozilla/Makefile ! make/sun/rmi/Makefile ! make/sun/security/Makefile ! make/sun/tracing/Makefile ! make/tools/Makefile Changeset: d7d8807fca86 Author: weijun Date: 2010-02-12 10:24 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d7d8807fca86 6925639: keytool -genkeypair -help missing dname option Reviewed-by: mullan ! src/share/classes/sun/security/tools/KeyTool.java Changeset: 74f493fae483 Author: mchung Date: 2010-02-12 11:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/74f493fae483 6925868: Eliminate pack200's dependency on logging Summary: Replace j.u.l.Logger with sun.util.logging.PlatformLogger Reviewed-by: alanb, forax ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java Changeset: 328c5d3974fe Author: mchung Date: 2010-02-15 10:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/328c5d3974fe Merge Changeset: 84792500750c Author: lana Date: 2010-02-17 10:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/84792500750c Merge Changeset: e83d9c0d5e95 Author: chegar Date: 2010-02-22 15:27 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e83d9c0d5e95 6912868: "java.net.useSystemProxies" behavior fails to check "use_same_proxy" in GNOME Reviewed-by: alanb, chegar Contributed-by: damjan.jov at gmail.com ! src/solaris/native/sun/net/spi/DefaultProxySelector.c + test/java/net/ProxySelector/SystemProxies.java Changeset: c96d6cb31723 Author: chegar Date: 2010-02-23 17:08 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c96d6cb31723 6365587: Proxy-Connection header sent through tunnel Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: b396584a3e64 Author: lana Date: 2010-02-23 10:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b396584a3e64 Merge - make/java/text/FILES_java.gmk Changeset: 03cd9e62961f Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/03cd9e62961f Added tag jdk7-b85 for changeset b396584a3e64 ! .hgtags From john.coomes at sun.com Tue Mar 9 06:24:27 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 14:24:27 +0000 Subject: hg: jdk7/hotspot/langtools: 11 new changesets Message-ID: <20100309142502.8A7E744442@hg.openjdk.java.net> Changeset: 7d9e3a15d2b3 Author: jjg Date: 2010-02-15 16:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7d9e3a15d2b3 6926555: 6921979 breaks TreePosTest Reviewed-by: darcy ! test/tools/javac/treepostests/TreePosTest.java Changeset: af18e3956985 Author: darcy Date: 2010-02-15 18:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/af18e3956985 6634138: Source generated in last round not compiled Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/T6403466.java + test/tools/javac/processing/6634138/Dummy.java + test/tools/javac/processing/6634138/ExerciseDependency.java + test/tools/javac/processing/6634138/T6634138.java Changeset: fe17a9dbef03 Author: darcy Date: 2010-02-15 20:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fe17a9dbef03 6926699: Annotation processing regression tests should typically return SourceVersion.latest Reviewed-by: jjg ! test/tools/javac/6341866/Anno.java ! test/tools/javac/T6406771.java ! test/tools/javac/T6411379.java ! test/tools/javac/T6423583.java ! test/tools/javac/T6855236.java ! test/tools/javac/api/6421111/T6421111.java ! test/tools/javac/api/6468404/T6468404.java ! test/tools/javac/api/T6412669.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/processing/6348499/A.java ! test/tools/javac/processing/6414633/A.java ! test/tools/javac/processing/6430209/T6430209.java ! test/tools/javac/processing/6430209/b6341534.java ! test/tools/javac/processing/T6439826.java ! test/tools/javac/processing/model/element/TypeParamBounds.java ! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/util/GetTypeElemBadArg.java ! test/tools/javac/processing/model/util/OverridesSpecEx.java Changeset: 631a273dac0f Author: darcy Date: 2010-02-15 20:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/631a273dac0f 6926703: apt tests should run with assertions enabled Reviewed-by: jjg ! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java Changeset: 16b9b7f45933 Author: darcy Date: 2010-02-17 14:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/16b9b7f45933 6927061: Refactor apt implemenation to use code from JSR 269 Reviewed-by: jjg ! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java Changeset: 67f0e05098fa Author: lana Date: 2010-02-17 10:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/67f0e05098fa Merge Changeset: 0fce6b64c258 Author: lana Date: 2010-02-17 16:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0fce6b64c258 Merge Changeset: a3be81d385ee Author: jjg Date: 2010-02-18 15:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a3be81d385ee 6927797: langtools/test/tools/javac/EarlyAssert.java fails when run with assertions enabled (-ea) Reviewed-by: darcy ! test/tools/javac/EarlyAssert.java + test/tools/javac/EarlyAssertWrapper.java Changeset: f25efdb55c99 Author: andrew Date: 2010-02-22 21:37 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/f25efdb55c99 6928623: Behaviour of VERBOSE=true on langtools build Summary: VERBOSE=true causes -diagnostics to be passed to ant rather than -debug Reviewed-by: jjg ! make/Makefile Changeset: 136bfc679462 Author: lana Date: 2010-02-23 10:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/136bfc679462 Merge Changeset: b816baf594e3 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b816baf594e3 Added tag jdk7-b85 for changeset 136bfc679462 ! .hgtags From Thomas.Rodriguez at Sun.COM Tue Mar 9 17:56:32 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 09 Mar 2010 17:56:32 -0800 Subject: Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files In-Reply-To: <4B8E7DC2.2010905@redhat.com> References: <4B1FC407.6010405@redhat.com> <4B477E05.5050207@redhat.com> <4B486278.9040005@redhat.com> <448B68EA-1FE2-430C-A534-A8598652C046@Sun.COM> <4B55D97D.4020001@redhat.com> <5D1BE1E0-B1D9-465F-A29F-A46802BD7F43@Sun.COM> <4B56D7E0.6020702@redhat.com> <401A9C44-0A14-49AB-A771-A049BC04AE12@Sun.COM> <4B8E7DC2.2010905@redhat.com> Message-ID: <8490C38C-31C0-437F-8B1C-A3F9E10E6678@Sun.COM> Testing all looked good so I've pushed this. Thanks! tom On Mar 3, 2010, at 7:18 AM, Andrew Haley wrote: > On 01/20/2010 05:35 PM, Tom Rodriguez wrote: >> >> On Jan 20, 2010, at 2:16 AM, Andrew Haley wrote: >> >>> On 01/19/2010 07:43 PM, Tom Rodriguez wrote: >>> >>>> So do you want to pursue making the SA work with a stripped >>>> libjvm.so or is requiring debug info to be installed acceptable? >>>> Sorry if I made this more complicated than you wanted. I think your >>>> original change is fine, but if the norm is being stripped then >>>> making these tools work in that situation would be good. >>> >>> Clearly it would be. Java programmers on Linux systems aren't used to >>> installing debuginfo, so it would be better all round if these tools >>> were to work without it. (And besides, the idea that the Windows port >>> might be better in any way irks me!) I'll have a look. >> >> So the brute force approach is to make all vtables visible in the >> dynamic symbol table. > > This patch does everything, I hope. It adds all vtables to the > dynamic symtab, it changes the ELF reader to use the dynamic symtab, > and it adds a debuginfo reader that works with every GNU/Linux system > I know of. > > Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev-3/ > > OK to commit? I guess I'll need a bug ID in the Sun database too. > > This is https://bugs.openjdk.java.net/show_bug.cgi?id=100126 > > Andrew. From Coleen.Phillimore at Sun.COM Thu Mar 11 13:06:17 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Thu, 11 Mar 2010 16:06:17 -0500 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B9104AF.5010106@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> Message-ID: <4B995B49.6060603@sun.com> I've added the test to the changeset and a script to run in our harness. Also in os_linux.cpp, I changed the SYS_gettid call to go through our os::Linux::gettid() because on at least one linux, syscall() returns a long int which gets a compilation warning with %d. open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 Andrew, please have a look since you're the contributor. Thanks, Coleen Coleen Phillimore wrote: > > Yes, definitely send the test case too. > > thanks, > Coleen > > Andrew Haley wrote: >> On 03/05/2010 05:25 PM, Coleen Phillimore wrote: >> >>> This looks good to me, there are a couple of questions. Can you use >>> /proc/self/maps instead of getting the tid? >>> >> >> Sure. I was being defensive because the manpage says: >> >> /proc/self >> >> This directory refers to the process accessing the /proc >> filesystem, and is identical to the /proc directory named by the >> process ID of the same process. >> >> which I thought meant the PID rather than the TID. However, the page >> is misleading: I just checked and /proc/self refers to the TID. (Not >> that it really matters, as the mappings will mostly be the same >> anyway.) >> >> >>> Also there's a 'my' instead of 'by' in the comments. >>> >> >> Fixed. >> >> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-3 >> >> By the way, I have a good regression test for this. Should I submit >> that too? >> >> Andrew. >> > From aph at redhat.com Fri Mar 12 01:44:06 2010 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Mar 2010 09:44:06 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B995B49.6060603@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> Message-ID: <4B9A0CE6.7010504@redhat.com> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: > > I've added the test to the changeset and a script to run in our harness. > > Also in os_linux.cpp, I changed the SYS_gettid call to go through our > os::Linux::gettid() because on at least one linux, syscall() returns a > long int which gets a compilation warning with %d. > > open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ > bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 > > Andrew, please have a look since you're the contributor. That's OK, but you don't need SYS_gettid. Please look at http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch I changed to "/proc/self/maps", as you requested. I think this is better. The copy of my webrev to cr.openjdk.java.net failed for some reason I don't understand. Apologies, Andrew. From ahughes at redhat.com Fri Mar 12 04:14:30 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 12 Mar 2010 12:14:30 +0000 Subject: Please review changes in hotspot source code In-Reply-To: <4B9A2076.1090600@redhat.com> References: <4B9A2076.1090600@redhat.com> Message-ID: <17c6771e1003120414p2ed0f227lc0b37052b5884ff7@mail.gmail.com> On 12 March 2010 11:07, Pavel Tisnovsky wrote: > Hi, > > please review changes in hotspot source code. Webrev is available at: > http://cr.openjdk.java.net/~ptisnovs/Gcc4.5Errors2/ > > These are minor changes fixing compile failure when -Wall -Werror flags are > used under gcc 4.5. In this case error message is "suggest parentheses > around ...something..." > > Thanks in advance > Pavel Tisnovsky > HotSpot changes should go to the HotSpot list as I mentioned on the last patch. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christian.Thalinger at Sun.COM Fri Mar 12 04:48:45 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 12 Mar 2010 13:48:45 +0100 Subject: Please review changes in hotspot source code In-Reply-To: <17c6771e1003120414p2ed0f227lc0b37052b5884ff7@mail.gmail.com> References: <4B9A2076.1090600@redhat.com> <17c6771e1003120414p2ed0f227lc0b37052b5884ff7@mail.gmail.com> Message-ID: <1268398126.22991.0.camel@macbook> On Fri, 2010-03-12 at 12:14 +0000, Andrew John Hughes wrote: > On 12 March 2010 11:07, Pavel Tisnovsky wrote: > > Hi, > > > > please review changes in hotspot source code. Webrev is available at: > > http://cr.openjdk.java.net/~ptisnovs/Gcc4.5Errors2/ > > > > These are minor changes fixing compile failure when -Wall -Werror flags are > > used under gcc 4.5. In this case error message is "suggest parentheses > > around ...something..." > > > > Thanks in advance > > Pavel Tisnovsky > > > > HotSpot changes should go to the HotSpot list as I mentioned on the last patch. I created: 6934483: GCC 4.5 errors "suggest parentheses around something..." when compiling with -Werror and -Wall And the changes look good. -- Christian From Christian.Thalinger at Sun.COM Fri Mar 12 04:53:22 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 12 Mar 2010 13:53:22 +0100 Subject: Please review changes in hotspot source code In-Reply-To: <1268398126.22991.0.camel@macbook> References: <4B9A2076.1090600@redhat.com> <17c6771e1003120414p2ed0f227lc0b37052b5884ff7@mail.gmail.com> <1268398126.22991.0.camel@macbook> Message-ID: <1268398403.22991.2.camel@macbook> On Fri, 2010-03-12 at 13:48 +0100, Christian Thalinger wrote: > On Fri, 2010-03-12 at 12:14 +0000, Andrew John Hughes wrote: > > On 12 March 2010 11:07, Pavel Tisnovsky wrote: > > > Hi, > > > > > > please review changes in hotspot source code. Webrev is available at: > > > http://cr.openjdk.java.net/~ptisnovs/Gcc4.5Errors2/ > > > > > > These are minor changes fixing compile failure when -Wall -Werror flags are > > > used under gcc 4.5. In this case error message is "suggest parentheses > > > around ...something..." > > > > > > Thanks in advance > > > Pavel Tisnovsky > > > > > > > HotSpot changes should go to the HotSpot list as I mentioned on the last patch. > > I created: > > 6934483: GCC 4.5 errors "suggest parentheses around something..." when > compiling with -Werror and -Wall > > And the changes look good. I forgot to ask, what HotSpot version is this patch against? Does current HS18, with this patch applied, build with GCC 4.5? -- Christian From Coleen.Phillimore at Sun.COM Fri Mar 12 11:35:31 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Fri, 12 Mar 2010 14:35:31 -0500 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B9A0CE6.7010504@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> Message-ID: <4B9A9783.1040901@sun.com> Hi, I checked this into the hotspot-rt repository. I thought I made aph the author but the job came through with my name on it. It also has me as a reviewer, which I thought that jcheck would flag. I don't know how to fix this, but I am willing to if someone tells me how. Coleen Andrew Haley wrote: > On 03/11/2010 09:06 PM, Coleen Phillimore wrote: > >> I've added the test to the changeset and a script to run in our harness. >> >> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >> os::Linux::gettid() because on at least one linux, syscall() returns a >> long int which gets a compilation warning with %d. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >> >> Andrew, please have a look since you're the contributor. >> > > That's OK, but you don't need SYS_gettid. > Please look at http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch > I changed to "/proc/self/maps", as you requested. I think this is better. > > The copy of my webrev to cr.openjdk.java.net failed for some reason > I don't understand. > > Apologies, > Andrew. > From daniel.daugherty at oracle.com Fri Mar 12 11:48:59 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 12 Mar 2010 12:48:59 -0700 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B9A9783.1040901@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4B9A9783.1040901@sun.com> Message-ID: <4B9A9AAB.2010400@oracle.com> On 3/12/2010 12:35 PM, Coleen Phillimore wrote: > > Hi, > I checked this into the hotspot-rt repository. I thought I made aph > the author but the job came through with my name on it. Since your user ID submitted the job, I'm pretty sure JPRT ignored your "Author" setting. I recommend setting the "Contributed by" field to aph at redhat.com for future submissions... > It also has me as a reviewer, which I thought that jcheck would flag. You had a second reviewer so "self review" is permitted... > I don't know how to fix this, but I am willing to if someone tells me > how. I don't think you can fix this. It is not as easy to tweak meta-data in Mercurial as it is in Teamware... Dan > > Coleen > > Andrew Haley wrote: >> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >> >>> I've added the test to the changeset and a script to run in our >>> harness. >>> >>> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >>> os::Linux::gettid() because on at least one linux, syscall() returns a >>> long int which gets a compilation warning with %d. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >>> >>> Andrew, please have a look since you're the contributor. >>> >> >> That's OK, but you don't need SYS_gettid. >> Please look at >> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch >> I changed to "/proc/self/maps", as you requested. I think this is >> better. >> >> The copy of my webrev to cr.openjdk.java.net failed for some reason >> I don't understand. >> >> Apologies, >> Andrew. >> > -- Dan Oracle Daniel Daugherty | Software Engineer Phone: +17194811796 | Mobile: +17192375807 Oracle Java Serviceability | Monument, Colorado 80132 Green Oracle Oracle is committed to developing practices and products that help protect the environment From Y.S.Ramakrishna at Sun.COM Fri Mar 12 12:04:31 2010 From: Y.S.Ramakrishna at Sun.COM (Y. Srinivas Ramakrishna) Date: Fri, 12 Mar 2010 12:04:31 -0800 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B9A9AAB.2010400@oracle.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <4B9A9783.1040901@sun.com> <4B9A9AAB.2010400@oracle.com> Message-ID: <4B9A9E4F.5020406@sun.com> daniel.daugherty at oracle.com wrote: > On 3/12/2010 12:35 PM, Coleen Phillimore wrote: >> >> Hi, >> I checked this into the hotspot-rt repository. I thought I made aph >> the author but the job came through with my name on it. > > Since your user ID submitted the job, I'm pretty sure JPRT ignored > your "Author" setting. I recommend setting the "Contributed by" field > to aph at redhat.com for future submissions... % hg commit -u aph ... should have worked. I've seen that work (and used it successfully) in the past. JPRT itself just pushes the changeset that you commit; it does not tweak the author field of the changeset (afaik). Hmm, did you use: % jprt submit -user aph ... after a vanilla % hs commit ... (without -u aph?) ? I don't _think_ that would work. -- ramki From karen.kinnear at sun.com Fri Mar 12 14:28:24 2010 From: karen.kinnear at sun.com (karen.kinnear at sun.com) Date: Fri, 12 Mar 2010 22:28:24 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20100312222834.1086D448E7@hg.openjdk.java.net> Changeset: c8a467bf56ad Author: coleenp Date: 2010-03-02 12:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c8a467bf56ad 6914050: jvm assertion "guard pages must be in use" in -Xcomp mode Summary: Move creating stack guard pages in jni attach thread before potential java call rather than after. Also cleanup stack guard pages when jni attach fails Reviewed-by: never, dholmes ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/thread.cpp Changeset: 4b0f2f4918ed Author: xlu Date: 2010-03-10 21:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b0f2f4918ed 6933402: RFE: Improve PrintSafepointStatistics output to track cleanup time Summary: Improve the usability of safepoint statistics data. See bug evaluation for more details. Reviewed-by: ysr, dholmes ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp Changeset: 12d91eb0f579 Author: acorn Date: 2010-03-11 14:41 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/12d91eb0f579 Merge From Christian.Thalinger at Sun.COM Tue Mar 16 06:01:07 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 16 Mar 2010 14:01:07 +0100 Subject: Please review changes in hotspot source code In-Reply-To: <1268398403.22991.2.camel@macbook> References: <4B9A2076.1090600@redhat.com> <17c6771e1003120414p2ed0f227lc0b37052b5884ff7@mail.gmail.com> <1268398126.22991.0.camel@macbook> <1268398403.22991.2.camel@macbook> Message-ID: <1268744468.26240.3.camel@macbook> On Fri, 2010-03-12 at 13:53 +0100, Christian Thalinger wrote: > > 6934483: GCC 4.5 errors "suggest parentheses around something..." when > > compiling with -Werror and -Wall > > > > And the changes look good. Since GCC 4.5 is not released yet, I postpone this CR. Please ping again when it's released. -- Christian From ahughes at redhat.com Wed Mar 17 07:15:17 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Wed, 17 Mar 2010 14:15:17 +0000 Subject: hs17 stabilisation Message-ID: <17c6771e1003170715q2404f662sbc943d231998859@mail.gmail.com> There seems to be some work on stabilising hs17 for the proprietary JDK6 builds: http://download.java.net/jdk6/6u20/promoted/b01/changes/JDK6u20.b01.list.html When will we see a public tree for this, like http://hg.openjdk.java.net/hsx/hsx16/ ? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Erik.Trimble at Sun.COM Wed Mar 17 10:38:23 2010 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Wed, 17 Mar 2010 10:38:23 -0700 Subject: hs17 stabilisation In-Reply-To: <17c6771e1003170715q2404f662sbc943d231998859@mail.gmail.com> References: <17c6771e1003170715q2404f662sbc943d231998859@mail.gmail.com> Message-ID: <1268847504.23244.1.camel@ghostbox.sfbay.sun.com> Yes. There is now an hsx/hsx17 tree which contains the work on Hotspot 17. We [read: I] will be pushing a Hotspot 18 fork changeset onto the main jdk7 repos sometime soon. -Erik On Wed, 2010-03-17 at 14:15 +0000, Andrew John Hughes wrote: > There seems to be some work on stabilising hs17 for the proprietary JDK6 builds: > > http://download.java.net/jdk6/6u20/promoted/b01/changes/JDK6u20.b01.list.html > > When will we see a public tree for this, like > http://hg.openjdk.java.net/hsx/hsx16/ ? -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From ahughes at redhat.com Wed Mar 17 14:58:55 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Wed, 17 Mar 2010 21:58:55 +0000 Subject: hs17 stabilisation In-Reply-To: <1268847504.23244.1.camel@ghostbox.sfbay.sun.com> References: <17c6771e1003170715q2404f662sbc943d231998859@mail.gmail.com> <1268847504.23244.1.camel@ghostbox.sfbay.sun.com> Message-ID: <17c6771e1003171458x744c8517me7fbd5b1bf731645@mail.gmail.com> On 17 March 2010 17:38, Erik Trimble wrote: > Yes. > > There is now an hsx/hsx17 ?tree which contains the work on Hotspot 17. > Thanks for the quick response on this! :-) > We [read: I] will be pushing a Hotspot 18 fork changeset onto the main > jdk7 repos sometime soon. > > > > -Erik > > > On Wed, 2010-03-17 at 14:15 +0000, Andrew John Hughes wrote: >> There seems to be some work on stabilising hs17 for the proprietary JDK6 builds: >> >> http://download.java.net/jdk6/6u20/promoted/b01/changes/JDK6u20.b01.list.html >> >> When will we see a public tree for this, like >> http://hg.openjdk.java.net/hsx/hsx16/ ? > -- > Erik Trimble > Java System Support > Mailstop: ?usca22-123 > Phone: ?x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From andreas.kohn at fredhopper.com Thu Mar 18 02:10:38 2010 From: andreas.kohn at fredhopper.com (Andreas Kohn) Date: Thu, 18 Mar 2010 10:10:38 +0100 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4B9A0CE6.7010504@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> Message-ID: <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> On Fri, 2010-03-12 at 09:44 +0000, Andrew Haley wrote: > On 03/11/2010 09:06 PM, Coleen Phillimore wrote: > > > > I've added the test to the changeset and a script to run in our harness. > > > > Also in os_linux.cpp, I changed the SYS_gettid call to go through our > > os::Linux::gettid() because on at least one linux, syscall() returns a > > long int which gets a compilation warning with %d. > > > > open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ > > bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 > > > > Andrew, please have a look since you're the contributor. > > That's OK, but you don't need SYS_gettid. > Please look at http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch > I changed to "/proc/self/maps", as you requested. I think this is better. > > The copy of my webrev to cr.openjdk.java.net failed for some reason > I don't understand. > With this change I seem to hit the limit on the number of open files. Looking through it, shouldn't get_stack_bounds() close the FILE* it opened? For example an eclipse process shows this: /proc/20662/fd>ls -al |grep -c /proc/20662/maps 1917 +static bool +get_stack_bounds(uintptr_t *bottom, uintptr_t *top) +{ + FILE *f = fopen("/proc/self/maps", "r"); <----- that one + if (f == NULL) + return false; + + while (!feof(f)) { + size_t dummy; + char *str = NULL; + ssize_t len = getline(&str, &dummy, f); + if (len == -1) { + return false; + } + + if (len > 0 && str[len-1] == '\n') { + str[len-1] = 0; + len--; + } + + static const char *stack_str = "[stack]"; + if (len > (ssize_t)strlen(stack_str) + && (strcmp(str + len - strlen(stack_str), stack_str) == 0)) { + if (sscanf(str, "%" SCNxPTR "-%" SCNxPTR, bottom, top) == 2) { + uintptr_t sp = (uintptr_t)__builtin_frame_address(0); + if (sp >= *bottom && sp <= *top) { + free(str); + return true; + } + } + } + + free(str); + } + + return false; +} Regards, -- Andreas -- Never attribute to malice that which can be adequately explained by stupidity. -- Hanlon's Razor -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100318/4a180fea/attachment.bin From aph at redhat.com Thu Mar 18 03:05:10 2010 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Mar 2010 10:05:10 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> Message-ID: <4BA1FAD6.8090508@redhat.com> On 03/18/2010 09:10 AM, Andreas Kohn wrote: > On Fri, 2010-03-12 at 09:44 +0000, Andrew Haley wrote: >> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >>> >>> I've added the test to the changeset and a script to run in our harness. >>> >>> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >>> os::Linux::gettid() because on at least one linux, syscall() returns a >>> long int which gets a compilation warning with %d. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >>> >>> Andrew, please have a look since you're the contributor. >> >> That's OK, but you don't need SYS_gettid. >> Please look at http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch >> I changed to "/proc/self/maps", as you requested. I think this is better. >> >> The copy of my webrev to cr.openjdk.java.net failed for some reason >> I don't understand. > > With this change I seem to hit the limit on the number of open files. > Looking through it, shouldn't get_stack_bounds() close the FILE* it > opened? Oh, how stupid of me! If this were gcc I'd just push a fix immediately as obvious/trivial, but I think we need a bug opened to push the change. (BTW, this happened because of a mistake translating the patch I wrote from using the C++ library into C. The original patch used an fstream, whose destructor closes the file. When I did the translation I missed the fact that I had to close the file manually.) Andrew. From Christian.Thalinger at Sun.COM Thu Mar 18 08:49:26 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 18 Mar 2010 15:49:26 +0000 Subject: hg: jdk7/hotspot/hotspot: 13 new changesets Message-ID: <20100318154953.DC16B440F1@hg.openjdk.java.net> Changeset: 51db1e4b379d Author: twisti Date: 2010-03-08 04:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/51db1e4b379d 6932536: JSR 292 modified JDK MethodHandlesTest fails on x86_64 Summary: A modified MethodHandlesTest revealed two bugs on x86_64. Reviewed-by: never, jrose ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: 7de45b5044c3 Author: never Date: 2010-03-09 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7de45b5044c3 6932270: Allow Java's ELF symtab reader to use separate debuginfo files Reviewed-by: never Contributed-by: Andrew Haley ! agent/src/os/linux/libproc_impl.c ! agent/src/os/linux/symtab.c ! agent/src/os/linux/symtab.h + make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/linux/makefiles/vm.make Changeset: 3cf667df43ef Author: twisti Date: 2010-03-09 20:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3cf667df43ef 6919934: JSR 292 needs to support x86 C1 Summary: This implements JSR 292 support for C1 x86. Reviewed-by: never, jrose, kvn ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/ci/ciCPCache.cpp ! src/share/vm/ci/ciCPCache.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/vframeArray.cpp Changeset: d8e270c4f609 Author: twisti Date: 2010-03-09 23:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d8e270c4f609 Merge Changeset: c466efa608d5 Author: roland Date: 2010-03-05 13:58 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c466efa608d5 6932496: c1: deoptimization of jsr subroutine fails on sparcv9 Summary: store jsr ret bci as intptr constant in c1 debug info Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LinearScan.cpp + test/compiler/6932496/Test6932496.java Changeset: da06d1795d84 Author: twisti Date: 2010-03-11 05:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/da06d1795d84 6934089: Zero 32-bit/64kb page fix Summary: The fix for 6927165 increased the number of shadow pages for 32-bit platforms and this causes a problem on systems with 64kb pages. Reviewed-by: twisti Contributed-by: Gary Benson ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp Changeset: 9eba43136cb5 Author: twisti Date: 2010-03-16 11:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9eba43136cb5 6934494: JSR 292 MethodHandles adapters should be generated into their own CodeBlob Summary: Passing a null pointer to an InvokeDynamic function call should lead to a NullPointerException. Reviewed-by: kvn, never ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/includeDB_core ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 428a9c451986 Author: kvn Date: 2010-03-16 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/428a9c451986 6935466: new CodeCache flushing code is not guarded by the flag Summary: Add missing guard. Reviewed-by: never ! src/share/vm/compiler/compileBroker.cpp Changeset: fc2c71045ada Author: twisti Date: 2010-03-17 10:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fc2c71045ada 6934966: JSR 292 add C1 logic for saved SP over MethodHandle calls Summary: The logic for x86 C1 to save the SP over MH calls is pretty straight forward but SPARC handles that differently. Reviewed-by: never, jrose ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp Changeset: 2484f4d6a54e Author: kvn Date: 2010-03-17 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2484f4d6a54e 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 Summary: Added missing counter decrement when substring search restarted. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp + test/compiler/6935535/Test.java Changeset: c047da02984c Author: never Date: 2010-03-17 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c047da02984c 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp + test/compiler/6930043/Test6930043.java Changeset: 76c1d7d13ec5 Author: twisti Date: 2010-03-18 09:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/76c1d7d13ec5 6932091: JSR 292 x86 code cleanup Summary: Some code cleanups found during the JSR 292 SPARC port. Reviewed-by: kvn, never ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 97fe2cc98b1d Author: twisti Date: 2010-03-18 06:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/97fe2cc98b1d Merge From Coleen.Phillimore at Sun.COM Thu Mar 18 10:35:00 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems) Date: Thu, 18 Mar 2010 13:35:00 -0400 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4BA1FAD6.8090508@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> <4BA1FAD6.8090508@redhat.com> Message-ID: <4BA26444.90609@sun.com> I filed bug 6936168 and have a repository with 3 additional fcloses() in them for the returns after the file is opened. See: open webrev at http://cr.openjdk.java.net/~coleenp/6936168/ bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6936168 It's running our tests that failed now. Please review this change and I'll push it back before it gets to the main hotspot repository (it's still in hotspot_rt right now). Thanks for reporting this. This would have taken us a while to diagnose. Sorry for the crummy code review the first time around. Coleen On 03/18/10 06:05, Andrew Haley wrote: > On 03/18/2010 09:10 AM, Andreas Kohn wrote: > >> On Fri, 2010-03-12 at 09:44 +0000, Andrew Haley wrote: >> >>> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >>> >>>> I've added the test to the changeset and a script to run in our harness. >>>> >>>> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >>>> os::Linux::gettid() because on at least one linux, syscall() returns a >>>> long int which gets a compilation warning with %d. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >>>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >>>> >>>> Andrew, please have a look since you're the contributor. >>>> >>> That's OK, but you don't need SYS_gettid. >>> Please look at http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch >>> I changed to "/proc/self/maps", as you requested. I think this is better. >>> >>> The copy of my webrev to cr.openjdk.java.net failed for some reason >>> I don't understand. >>> >> With this change I seem to hit the limit on the number of open files. >> Looking through it, shouldn't get_stack_bounds() close the FILE* it >> opened? >> > > Oh, how stupid of me! If this were gcc I'd just push a fix > immediately as obvious/trivial, but I think we need a bug opened to > push the change. > > (BTW, this happened because of a mistake translating the patch I wrote > from using the C++ library into C. The original patch used an > fstream, whose destructor closes the file. When I did the translation > I missed the fact that I had to close the file manually.) > > Andrew. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100318/46297a20/attachment-0001.html From aph at redhat.com Thu Mar 18 10:46:51 2010 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Mar 2010 17:46:51 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4BA26444.90609@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> <4BA1FAD6.8090508@redhat.com> <4BA26444.90609@sun.com> Message-ID: <4BA2670B.8030804@redhat.com> Yes, thanks indeed. Andrew. On 03/18/2010 05:35 PM, Coleen Phillimore - Sun Microsystems wrote: > > I filed bug 6936168 and have a repository with 3 additional fcloses() > in them for the returns after the file is opened. See: > > open webrev at http://cr.openjdk.java.net/~coleenp/6936168/ > bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6936168 > > It's running our tests that failed now. Please review this change and > I'll push it back before it gets to the main hotspot repository (it's > still in hotspot_rt right now). > > Thanks for reporting this. This would have taken us a while to > diagnose. Sorry for the crummy code review the first time around. > > Coleen > > On 03/18/10 06:05, Andrew Haley wrote: >> On 03/18/2010 09:10 AM, Andreas Kohn wrote: >> >>> On Fri, 2010-03-12 at 09:44 +0000, Andrew Haley wrote: >>> >>>> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >>>> >>>>> I've added the test to the changeset and a script to run in our >>>>> harness. >>>>> >>>>> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >>>>> os::Linux::gettid() because on at least one linux, syscall() returns a >>>>> long int which gets a compilation warning with %d. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >>>>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >>>>> >>>>> Andrew, please have a look since you're the contributor. >>>>> >>>> That's OK, but you don't need SYS_gettid. >>>> Please look at >>>> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch >>>> I changed to "/proc/self/maps", as you requested. I think this is >>>> better. >>>> >>>> The copy of my webrev to cr.openjdk.java.net failed for some reason >>>> I don't understand. >>>> >>> With this change I seem to hit the limit on the number of open files. >>> Looking through it, shouldn't get_stack_bounds() close the FILE* it >>> opened? >>> >> >> Oh, how stupid of me! If this were gcc I'd just push a fix >> immediately as obvious/trivial, but I think we need a bug opened to >> push the change. >> >> (BTW, this happened because of a mistake translating the patch I wrote >> from using the C++ library into C. The original patch used an >> fstream, whose destructor closes the file. When I did the translation >> I missed the fact that I had to close the file manually.) >> >> Andrew. >> > From Coleen.Phillimore at Sun.COM Thu Mar 18 10:48:47 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems) Date: Thu, 18 Mar 2010 13:48:47 -0400 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4BA2670B.8030804@redhat.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> <4BA1FAD6.8090508@redhat.com> <4BA26444.90609@sun.com> <4BA2670B.8030804@redhat.com> Message-ID: <4BA2677F.2000905@sun.com> Andrew, Since I missed the contributed by in the last putback, this one will look like this: 6936168: Recent fix for unmapping stack guard pages doesn't close /proc/self/maps Summary: Add close to returns (fix for 6929067 also contributed by aph) Contributed-by: aph at redhat.com Reviewed-by: coleenp, aph It would be nice if we had one more reviewer.... Thanks, Coleen On 03/18/10 13:46, Andrew Haley wrote: > Yes, thanks indeed. > > Andrew. > > > On 03/18/2010 05:35 PM, Coleen Phillimore - Sun Microsystems wrote: > >> I filed bug 6936168 and have a repository with 3 additional fcloses() >> in them for the returns after the file is opened. See: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6936168/ >> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6936168 >> >> It's running our tests that failed now. Please review this change and >> I'll push it back before it gets to the main hotspot repository (it's >> still in hotspot_rt right now). >> >> Thanks for reporting this. This would have taken us a while to >> diagnose. Sorry for the crummy code review the first time around. >> >> Coleen >> >> On 03/18/10 06:05, Andrew Haley wrote: >> >>> On 03/18/2010 09:10 AM, Andreas Kohn wrote: >>> >>> >>>> On Fri, 2010-03-12 at 09:44 +0000, Andrew Haley wrote: >>>> >>>> >>>>> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >>>>> >>>>> >>>>>> I've added the test to the changeset and a script to run in our >>>>>> harness. >>>>>> >>>>>> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >>>>>> os::Linux::gettid() because on at least one linux, syscall() returns a >>>>>> long int which gets a compilation warning with %d. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >>>>>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >>>>>> >>>>>> Andrew, please have a look since you're the contributor. >>>>>> >>>>>> >>>>> That's OK, but you don't need SYS_gettid. >>>>> Please look at >>>>> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch >>>>> I changed to "/proc/self/maps", as you requested. I think this is >>>>> better. >>>>> >>>>> The copy of my webrev to cr.openjdk.java.net failed for some reason >>>>> I don't understand. >>>>> >>>>> >>>> With this change I seem to hit the limit on the number of open files. >>>> Looking through it, shouldn't get_stack_bounds() close the FILE* it >>>> opened? >>>> >>>> >>> Oh, how stupid of me! If this were gcc I'd just push a fix >>> immediately as obvious/trivial, but I think we need a bug opened to >>> push the change. >>> >>> (BTW, this happened because of a mistake translating the patch I wrote >>> from using the C++ library into C. The original patch used an >>> fstream, whose destructor closes the file. When I did the translation >>> I missed the fact that I had to close the file manually.) >>> >>> Andrew. >>> >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100318/37730dce/attachment.html From daniel.daugherty at oracle.com Thu Mar 18 11:03:49 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 18 Mar 2010 12:03:49 -0600 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4BA2677F.2000905@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> <4BA1FAD6.8090508@redhat.com> <4BA26444.90609@sun.com> <4BA2670B.8030804@redhat.com> <4BA2677F.2000905@sun.com> Message-ID: <4BA26B05.20906@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100318/19ca4a2a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100318/19ca4a2a/attachment.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: green-for-email-sig_0.gif Type: image/gif Size: 356 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100318/19ca4a2a/attachment-0001.gif From ahughes at redhat.com Thu Mar 18 11:25:42 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 18 Mar 2010 18:25:42 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4BA2677F.2000905@sun.com> References: <4B83FF49.6060004@redhat.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> <4BA1FAD6.8090508@redhat.com> <4BA26444.90609@sun.com> <4BA2670B.8030804@redhat.com> <4BA2677F.2000905@sun.com> Message-ID: <17c6771e1003181125q7062d0fcod77a00afdf495352@mail.gmail.com> On 18 March 2010 17:48, Coleen Phillimore - Sun Microsystems wrote: > > Andrew, Since I missed the contributed by in the last putback, this one will > look like this: > > 6936168: Recent fix for unmapping stack guard pages doesn't close > /proc/self/maps > Summary: Add close to returns (fix for 6929067 also contributed by aph) > Contributed-by: aph at redhat.com > Reviewed-by: coleenp, aph > > It would be nice if we had one more reviewer.... > Looks good to me, so feel free to add me to the list. Is there a roadmap for allowing external access to JPRT so those with commit access like me and Andrew can push HotSpot patches ourselves? > Thanks, > Coleen > > On 03/18/10 13:46, Andrew Haley wrote: > > Yes, thanks indeed. > > Andrew. > > > On 03/18/2010 05:35 PM, Coleen Phillimore - Sun Microsystems wrote: > > > I filed bug 6936168 and have a repository with 3 additional fcloses() > in them for the returns after the file is opened. See: > > open webrev at http://cr.openjdk.java.net/~coleenp/6936168/ > bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6936168 > > It's running our tests that failed now. Please review this change and > I'll push it back before it gets to the main hotspot repository (it's > still in hotspot_rt right now). > > Thanks for reporting this. This would have taken us a while to > diagnose. Sorry for the crummy code review the first time around. > > Coleen > > On 03/18/10 06:05, Andrew Haley wrote: > > > On 03/18/2010 09:10 AM, Andreas Kohn wrote: > > > > On Fri, 2010-03-12 at 09:44 +0000, Andrew Haley wrote: > > > > On 03/11/2010 09:06 PM, Coleen Phillimore wrote: > > > > I've added the test to the changeset and a script to run in our > harness. > > Also in os_linux.cpp, I changed the SYS_gettid call to go through our > os::Linux::gettid() because on at least one linux, syscall() returns a > long int which gets a compilation warning with %d. > > open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ > bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 > > Andrew, please have a look since you're the contributor. > > > > That's OK, but you don't need SYS_gettid. > Please look at > http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch > I changed to "/proc/self/maps", as you requested. I think this is > better. > > The copy of my webrev to cr.openjdk.java.net failed for some reason > I don't understand. > > > > With this change I seem to hit the limit on the number of open files. > Looking through it, shouldn't get_stack_bounds() close the FILE* it > opened? > > > > Oh, how stupid of me! If this were gcc I'd just push a fix > immediately as obvious/trivial, but I think we need a bug opened to > push the change. > > (BTW, this happened because of a mistake translating the patch I wrote > from using the C++ library into C. The original patch used an > fstream, whose destructor closes the file. When I did the translation > I missed the fact that I had to close the file manually.) > > Andrew. > > > > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Coleen.Phillimore at Sun.COM Thu Mar 18 11:39:24 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems) Date: Thu, 18 Mar 2010 14:39:24 -0400 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <17c6771e1003181125q7062d0fcod77a00afdf495352@mail.gmail.com> References: <4B83FF49.6060004@redhat.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> <4BA1FAD6.8090508@redhat.com> <4BA26444.90609@sun.com> <4BA2670B.8030804@redhat.com> <4BA2677F.2000905@sun.com> <17c6771e1003181125q7062d0fcod77a00afdf495352@mail.gmail.com> Message-ID: <4BA2735C.2070105@sun.com> On 03/18/10 14:25, Andrew John Hughes wrote: > On 18 March 2010 17:48, Coleen Phillimore - Sun Microsystems > wrote: > >> Andrew, Since I missed the contributed by in the last putback, this one will >> look like this: >> >> 6936168: Recent fix for unmapping stack guard pages doesn't close >> /proc/self/maps >> Summary: Add close to returns (fix for 6929067 also contributed by aph) >> Contributed-by: aph at redhat.com >> Reviewed-by: coleenp, aph >> >> It would be nice if we had one more reviewer.... >> >> > > Looks good to me, so feel free to add me to the list. > Thanks! > Is there a roadmap for allowing external access to JPRT so those with > commit access like me and Andrew can push HotSpot patches ourselves? > > I have no idea about that. Thanks, Coleen >> Thanks, >> Coleen >> >> On 03/18/10 13:46, Andrew Haley wrote: >> >> Yes, thanks indeed. >> >> Andrew. >> >> >> On 03/18/2010 05:35 PM, Coleen Phillimore - Sun Microsystems wrote: >> >> >> I filed bug 6936168 and have a repository with 3 additional fcloses() >> in them for the returns after the file is opened. See: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6936168/ >> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6936168 >> >> It's running our tests that failed now. Please review this change and >> I'll push it back before it gets to the main hotspot repository (it's >> still in hotspot_rt right now). >> >> Thanks for reporting this. This would have taken us a while to >> diagnose. Sorry for the crummy code review the first time around. >> >> Coleen >> >> On 03/18/10 06:05, Andrew Haley wrote: >> >> >> On 03/18/2010 09:10 AM, Andreas Kohn wrote: >> >> >> >> On Fri, 2010-03-12 at 09:44 +0000, Andrew Haley wrote: >> >> >> >> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >> >> >> >> I've added the test to the changeset and a script to run in our >> harness. >> >> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >> os::Linux::gettid() because on at least one linux, syscall() returns a >> long int which gets a compilation warning with %d. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >> >> Andrew, please have a look since you're the contributor. >> >> >> >> That's OK, but you don't need SYS_gettid. >> Please look at >> http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch >> I changed to "/proc/self/maps", as you requested. I think this is >> better. >> >> The copy of my webrev to cr.openjdk.java.net failed for some reason >> I don't understand. >> >> >> >> With this change I seem to hit the limit on the number of open files. >> Looking through it, shouldn't get_stack_bounds() close the FILE* it >> opened? >> >> >> >> Oh, how stupid of me! If this were gcc I'd just push a fix >> immediately as obvious/trivial, but I think we need a bug opened to >> push the change. >> >> (BTW, this happened because of a mistake translating the patch I wrote >> from using the C++ library into C. The original patch used an >> fstream, whose destructor closes the file. When I did the translation >> I missed the fact that I had to close the file manually.) >> >> Andrew. >> >> >> >> >> > > > Thanks, > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100318/fbbb3d16/attachment.html From erik.trimble at sun.com Thu Mar 18 16:08:36 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Thu, 18 Mar 2010 23:08:36 +0000 Subject: hg: jdk7/hotspot/hotspot: 31 new changesets Message-ID: <20100318231013.000944415D@hg.openjdk.java.net> Changeset: 26ecc6fa29e6 Author: mikejwre Date: 2010-02-04 11:19 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/26ecc6fa29e6 Added tag jdk7-b82 for changeset 1999f5b12482 ! .hgtags Changeset: 1e3c5d0474d4 Author: trims Date: 2010-02-05 16:21 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1e3c5d0474d4 Merge Changeset: 39e0a32bc49b Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/39e0a32bc49b Added tag hs17-b01 for changeset a94714c55065 ! .hgtags Changeset: bd1260aafd87 Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bd1260aafd87 Added tag hs17-b02 for changeset faf94d94786b ! .hgtags Changeset: d9c445aa7bb1 Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d9c445aa7bb1 Added tag hs17-b03 for changeset f4b900403d6e ! .hgtags Changeset: 3940517a1f13 Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3940517a1f13 Added tag hs17-b04 for changeset d8dd291a362a ! .hgtags Changeset: 4458e32d9125 Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4458e32d9125 Added tag hs17-b05 for changeset 9174bb32e934 ! .hgtags Changeset: 36a78dac746f Author: trims Date: 2010-02-11 19:52 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/36a78dac746f Added tag hs17-b06 for changeset a5a6adfca6ec ! .hgtags Changeset: bfa6d67a7a29 Author: trims Date: 2010-02-11 19:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bfa6d67a7a29 Added tag hs17-b07 for changeset 3003ddd1d433 ! .hgtags Changeset: 73047d0b13cf Author: trims Date: 2010-02-11 19:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/73047d0b13cf Added tag hs17-b08 for changeset 1f9b07674480 ! .hgtags Changeset: 12076a98a540 Author: trims Date: 2010-02-11 19:53 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/12076a98a540 Added tag hs17-b09 for changeset ff3232b68fbb ! .hgtags Changeset: 704a172a0918 Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/704a172a0918 Added tag hs16-b01 for changeset 981375ca07b7 ! .hgtags Changeset: e114a6374471 Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e114a6374471 Added tag hs16-b02 for changeset f4cbf78110c7 ! .hgtags Changeset: 3469eafe9bf4 Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3469eafe9bf4 Added tag hs16-b03 for changeset 07c1c01e0315 ! .hgtags Changeset: 26dba59fc9ec Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/26dba59fc9ec Added tag hs16-b04 for changeset 08f86fa55a31 ! .hgtags Changeset: 8b0989046c93 Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8b0989046c93 Added tag hs16-b05 for changeset 32c83fb84370 ! .hgtags Changeset: 5fe06b3f6753 Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5fe06b3f6753 Added tag hs16-b06 for changeset ba313800759b ! .hgtags Changeset: 36ae83035b8e Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/36ae83035b8e Added tag hs16-b07 for changeset 3c0f72981560 ! .hgtags Changeset: 89ef87b378cd Author: trims Date: 2010-02-11 20:11 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/89ef87b378cd Added tag hs16-b08 for changeset ac59d4e6dae5 ! .hgtags Changeset: cd89ef31a9c8 Author: trims Date: 2010-02-11 20:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cd89ef31a9c8 Added tag hs15-b01 for changeset 3f844a28c5f4 ! .hgtags Changeset: 2099657b92a1 Author: trims Date: 2010-02-11 20:36 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2099657b92a1 Added tag hs15-b02 for changeset 1605bb4eb5a7 ! .hgtags Changeset: 9dcad51c5c70 Author: trims Date: 2010-02-11 20:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9dcad51c5c70 Added tag hs15-b03 for changeset 2581d90c6c9b ! .hgtags Changeset: 07118aaebf50 Author: trims Date: 2010-02-11 20:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/07118aaebf50 Added tag hs15-b04 for changeset 9ab385cb0c42 ! .hgtags Changeset: 3f370a32906e Author: trims Date: 2010-02-11 20:37 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3f370a32906e Added tag hs15-b05 for changeset fafab5d5349c ! .hgtags Changeset: ffc8d176b84b Author: mikejwre Date: 2010-02-12 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ffc8d176b84b Added tag jdk7-b83 for changeset 3f370a32906e ! .hgtags Changeset: 125eb6a9fccf Author: mikejwre Date: 2010-02-18 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/125eb6a9fccf Added tag jdk7-b84 for changeset ffc8d176b84b ! .hgtags Changeset: 1f341bb67b5b Author: trims Date: 2010-02-18 22:15 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1f341bb67b5b Merge Changeset: 6c9796468b91 Author: trims Date: 2010-02-18 22:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6c9796468b91 6927886: Bump the HS17 build number to 10 Summary: Update the HS17 build number to 10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 418bc80ce139 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/418bc80ce139 Added tag jdk7-b85 for changeset 6c9796468b91 ! .hgtags Changeset: bf823ef06b4f Author: trims Date: 2010-03-08 15:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bf823ef06b4f Added tag hs17-b10 for changeset 418bc80ce139 ! .hgtags Changeset: 6c94fe3c8df3 Author: trims Date: 2010-03-18 16:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6c94fe3c8df3 Merge From thomas.rodriguez at sun.com Thu Mar 18 16:44:52 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 18 Mar 2010 23:44:52 +0000 Subject: hg: hsx/hsx17/baseline: 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I Message-ID: <20100318234457.9019144166@hg.openjdk.java.net> Changeset: f3fb145b87ba Author: never Date: 2010-03-18 13:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/f3fb145b87ba 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp + test/compiler/6930043/Test6930043.java From andreas.kohn at fredhopper.com Fri Mar 19 00:34:48 2010 From: andreas.kohn at fredhopper.com (Andreas Kohn) Date: Fri, 19 Mar 2010 08:34:48 +0100 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4BA26444.90609@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> <4BA1FAD6.8090508@redhat.com> <4BA26444.90609@sun.com> Message-ID: <41F5F646-677B-4505-9E4C-81134E94D1B5@fredhopper.com> On 18.03.2010, at 18:35, Coleen Phillimore - Sun Microsystems wrote: > > I filed bug 6936168 and have a repository with 3 additional fcloses > () in them for the returns after the file is opened. See: > > open webrev at http://cr.openjdk.java.net/~coleenp/6936168/ With this change everything seems to work properly again :) Thanks, -- Andreas > > Coleen > > On 03/18/10 06:05, Andrew Haley wrote: >> >> On 03/18/2010 09:10 AM, Andreas Kohn wrote: >> >>> On Fri, 2010-03-12 at 09:44 +0000, Andrew Haley wrote: >>> >>>> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >>>> >>>>> I've added the test to the changeset and a script to run in our >>>>> harness. >>>>> >>>>> Also in os_linux.cpp, I changed the SYS_gettid call to go >>>>> through our >>>>> os::Linux::gettid() because on at least one linux, syscall() >>>>> returns a >>>>> long int which gets a compilation warning with %d. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >>>>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >>>>> >>>>> Andrew, please have a look since you're the contributor. >>>>> >>>> That's OK, but you don't need SYS_gettid. >>>> Please look at http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch >>>> I changed to "/proc/self/maps", as you requested. I think this >>>> is better. >>>> >>>> The copy of my webrev to cr.openjdk.java.net failed for some reason >>>> I don't understand. >>>> >>> With this change I seem to hit the limit on the number of open >>> files. >>> Looking through it, shouldn't get_stack_bounds() close the FILE* it >>> opened? >>> >> >> Oh, how stupid of me! If this were gcc I'd just push a fix >> immediately as obvious/trivial, but I think we need a bug opened to >> push the change. >> >> (BTW, this happened because of a mistake translating the patch I >> wrote >> from using the C++ library into C. The original patch used an >> fstream, whose destructor closes the file. When I did the >> translation >> I missed the fact that I had to close the file manually.) >> >> Andrew. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100319/b1195d9d/attachment.html From john.coomes at sun.com Fri Mar 19 01:35:39 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 08:35:39 +0000 Subject: hg: jdk7/hotspot: 4 new changesets Message-ID: <20100319083539.821C8441FD@hg.openjdk.java.net> Changeset: 4d7419e4b759 Author: ohair Date: 2010-03-06 15:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/4d7419e4b759 6928700: Configure top repo for JPRT testing Reviewed-by: alanb, jjg ! make/jprt.properties + test/Makefile Changeset: f3664d6879ab Author: ohair Date: 2010-03-06 15:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/f3664d6879ab Merge Changeset: 433a60a9c0bf Author: lana Date: 2010-03-09 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/433a60a9c0bf Merge Changeset: 6b1069f53fbc Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/6b1069f53fbc Added tag jdk7-b86 for changeset 433a60a9c0bf ! .hgtags From john.coomes at sun.com Fri Mar 19 01:35:45 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 08:35:45 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b86 for changeset 6253e28826d1 Message-ID: <20100319083548.9A0EE441FE@hg.openjdk.java.net> Changeset: 09a41111a401 Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/09a41111a401 Added tag jdk7-b86 for changeset 6253e28826d1 ! .hgtags From john.coomes at sun.com Fri Mar 19 01:39:14 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 08:39:14 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b86 for changeset 81c0f115bbe5 Message-ID: <20100319083914.96AAA441FF@hg.openjdk.java.net> Changeset: 8b493f1aa136 Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/8b493f1aa136 Added tag jdk7-b86 for changeset 81c0f115bbe5 ! .hgtags From john.coomes at sun.com Fri Mar 19 01:39:20 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 08:39:20 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b86 for changeset 512b0e924a5a Message-ID: <20100319083920.8221144200@hg.openjdk.java.net> Changeset: 3febd6fab2ac Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/3febd6fab2ac Added tag jdk7-b86 for changeset 512b0e924a5a ! .hgtags From john.coomes at sun.com Fri Mar 19 01:40:27 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 08:40:27 +0000 Subject: hg: jdk7/hotspot/jdk: 40 new changesets Message-ID: <20100319085330.CB3E344204@hg.openjdk.java.net> Changeset: 840601ac5ab7 Author: rkennke Date: 2010-03-03 15:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/840601ac5ab7 6892485: Deadlock in SunGraphicsEnvironment / FontManager Summary: Synchronize on correct monitor in SunFontManager. Reviewed-by: igor, prr ! src/share/classes/sun/font/SunFontManager.java Changeset: 1d7db2d5c4c5 Author: minqi Date: 2010-03-08 11:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1d7db2d5c4c5 6918065: Crash in Java2D blit loop (IntArgbToIntArgbPreSrcOverMaskBlit) in 64bit mode Reviewed-by: igor, bae ! src/share/classes/java/awt/AlphaComposite.java + test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java Changeset: 494f5e4f24da Author: lana Date: 2010-03-09 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/494f5e4f24da Merge Changeset: e64331144648 Author: rupashka Date: 2010-02-10 15:15 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e64331144648 6848475: JSlider does not display the correct value of its BoundedRangeModel Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6848475/bug6848475.java Changeset: f81c8041ccf4 Author: peytoia Date: 2010-02-11 15:58 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f81c8041ccf4 6909002: Remove indicim.jar and thaiim.jar from JRE and move to samples if needed Reviewed-by: okutsu ! make/com/sun/Makefile Changeset: e2b58a45a426 Author: peytoia Date: 2010-02-12 14:38 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e2b58a45a426 6921289: (tz) Support tzdata2010b Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: e8340332745e Author: malenkov Date: 2010-02-18 17:46 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e8340332745e 4498236: RFE: Provide a toString method for PropertyChangeEvent and other classes Reviewed-by: peterz ! src/share/classes/java/beans/BeanDescriptor.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/FeatureDescriptor.java ! src/share/classes/java/beans/IndexedPropertyChangeEvent.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyChangeEvent.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test4498236.java Changeset: 5c03237838e1 Author: rupashka Date: 2010-02-27 14:26 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5c03237838e1 6913758: Specification for SynthViewportUI.paintBorder(...) should mention that this method is never called Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java Changeset: 96205ed1b196 Author: rupashka Date: 2010-02-27 14:47 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/96205ed1b196 6918447: SynthToolBarUI.setBorderToXXXX() methods don't correspond inherited spec. They do nothing. Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java Changeset: 621e921a14cd Author: rupashka Date: 2010-02-27 15:09 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/621e921a14cd 6918861: SynthSliderUI.uninstallDefaults() is not called when UI is uninstalled Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java + test/javax/swing/JSlider/6918861/bug6918861.java Changeset: 28741de0bb4a Author: rupashka Date: 2010-02-27 16:03 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/28741de0bb4a 6923305: SynthSliderUI paints the slider track when the slider's "paintTrack" property is set to false Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java + test/javax/swing/JSlider/6923305/bug6923305.java Changeset: 2bf137beb9bd Author: rupashka Date: 2010-02-27 16:14 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2bf137beb9bd 6929298: The SynthSliderUI#calculateTickRect method should be removed Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java Changeset: d6b3a07c8752 Author: rupashka Date: 2010-03-03 17:57 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d6b3a07c8752 6924059: SynthScrollBarUI.configureScrollBarColors() should have spec different from the overridden method Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java + test/javax/swing/JScrollBar/6924059/bug6924059.java Changeset: 30c520bd148f Author: rupashka Date: 2010-03-03 20:08 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/30c520bd148f 6913768: With default SynthLookAndFeel instance installed new JTable creation leads to throwing NPE Reviewed-by: peterz ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java + test/javax/swing/JTable/6913768/bug6913768.java Changeset: f13fc955be62 Author: rupashka Date: 2010-03-03 20:53 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f13fc955be62 6917744: JScrollPane Page Up/Down keys do not handle correctly html tables with different cells contents Reviewed-by: peterz, alexp ! src/share/classes/javax/swing/text/DefaultEditorKit.java + test/javax/swing/JEditorPane/6917744/bug6917744.java + test/javax/swing/JEditorPane/6917744/test.html Changeset: 0622086d82ac Author: malenkov Date: 2010-03-04 21:17 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0622086d82ac 6921644: XMLEncoder generates invalid XML Reviewed-by: peterz ! src/share/classes/java/beans/XMLEncoder.java + test/java/beans/XMLEncoder/Test5023550.java + test/java/beans/XMLEncoder/Test5023557.java + test/java/beans/XMLEncoder/Test6921644.java Changeset: 79a509ac8f35 Author: lana Date: 2010-03-01 18:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/79a509ac8f35 Merge ! make/com/sun/Makefile - make/java/text/FILES_java.gmk Changeset: 90248595ec35 Author: lana Date: 2010-03-04 13:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/90248595ec35 Merge Changeset: 2fe4e72288ce Author: lana Date: 2010-03-09 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2fe4e72288ce Merge Changeset: 38fbb2353a6a Author: alanb Date: 2010-02-23 17:56 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/38fbb2353a6a 6925977: (file) test/java/nio/file/Path/CheckPermissions.java fails if test.src on read-only file system Reviewed-by: chegar ! test/java/nio/file/Path/CheckPermissions.java Changeset: 00abf8c232be Author: alanb Date: 2010-02-23 17:58 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/00abf8c232be 6925932: (file) Path.endsWith can throw ArrayIndexOutOfBoundsException (unx) Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/UnixPath.java ! test/java/nio/file/Path/PathOps.java Changeset: be5db597f3be Author: alanb Date: 2010-02-23 18:19 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/be5db597f3be 6928960: make modules fails to build class analyzer Reviewed-by: mchung ! make/modules/tools/Makefile Changeset: e94b296b53b4 Author: alanb Date: 2010-02-23 18:21 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e94b296b53b4 6926800: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with newer versions of find(1) Reviewed-by: forax ! test/java/nio/file/Files/PrintFileTree.java ! test/java/nio/file/Files/walk_file_tree.sh Changeset: e842e99b514a Author: darcy Date: 2010-02-24 10:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e842e99b514a 6929382: Various core classes in util and elsewhere are missing @param tags Reviewed-by: dholmes, martin ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Iterator.java ! src/share/classes/java/util/List.java Changeset: 9929203a8b98 Author: xuelei Date: 2010-02-25 13:32 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9929203a8b98 6916202: More cases of invalid ldap filters accepted and processed Reviewed-by: vinnie, weijun ! src/share/classes/com/sun/jndi/ldap/Filter.java + test/com/sun/jndi/ldap/InvalidLdapFilters.java Changeset: 77beb60b39c6 Author: alanb Date: 2010-02-27 18:18 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/77beb60b39c6 6929532: (file) WatchService should avoid queuing new modify events when lots of files are changing Reviewed-by: alanb Contributed-by: sebastian.sickelmann at gmx.de ! src/share/classes/sun/nio/fs/AbstractWatchKey.java + test/java/nio/file/WatchService/LotsOfEvents.java - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: b77e94f5a601 Author: alanb Date: 2010-02-27 19:15 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b77e94f5a601 6929259: Remove double spaces from Dual-pivot quicksort Reviewed-by: alanb Contributed-by: vladimir.yaroslavskiy at sun.com ! src/share/classes/java/util/DualPivotQuicksort.java Changeset: 529d2da0aee2 Author: alanb Date: 2010-02-27 19:26 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/529d2da0aee2 6815768: File.getxxxSpace() methods fail for very large file systems under 32bit Java Reviewed-by: ohair ! src/solaris/native/java/io/UnixFileSystem_md.c Changeset: f7a6eae6e1eb Author: alanb Date: 2010-02-27 19:29 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f7a6eae6e1eb 6921374: java.lang.String::hashCode() should check for count == 0 to avoid repeated stores hash = 0 Reviewed-by: darcy, ohair ! src/share/classes/java/lang/String.java Changeset: 78d91c4223cb Author: vinnie Date: 2010-03-01 17:54 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/78d91c4223cb 6921001: api/java_security/IdentityScope/IdentityScopeTests.html#getSystemScope fails starting from b78 JDK7 Reviewed-by: mullan ! src/share/classes/java/security/IdentityScope.java ! src/share/lib/security/java.security + test/java/security/IdentityScope/NoDefaultSystemScope.java Changeset: 893034df4ec2 Author: vinnie Date: 2010-03-01 18:00 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/893034df4ec2 Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: cddb43b12d28 Author: alanb Date: 2010-03-03 16:09 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cddb43b12d28 6931216: TEST_BUG: test/java/nio/file/WatchService/LotsOfEvents.java failed with NPE Reviewed-by: chegar ! test/java/nio/file/WatchService/LotsOfEvents.java Changeset: 507159d8d143 Author: ohair Date: 2010-03-03 11:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/507159d8d143 6931763: sanity checks broken with latest cygwin, newer egrep -i option problems Reviewed-by: jjg ! make/common/shared/Sanity.gmk Changeset: 61c298558549 Author: weijun Date: 2010-03-04 10:37 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/61c298558549 6844909: support allow_weak_crypto in krb5.conf Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/crypto/EType.java + test/sun/security/krb5/etype/WeakCrypto.java + test/sun/security/krb5/etype/weakcrypto.conf Changeset: 0f383673ce31 Author: weijun Date: 2010-03-04 10:38 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0f383673ce31 6923681: Jarsigner crashes during timestamping Reviewed-by: vinnie ! src/share/classes/sun/security/tools/TimestampedSigner.java Changeset: 5e15b70e6d27 Author: weijun Date: 2010-03-04 10:38 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/5e15b70e6d27 6880321: sun.security.provider.JavaKeyStore abuse of OOM Exception handling Reviewed-by: xuelei ! src/share/classes/sun/security/provider/JavaKeyStore.java Changeset: c2d29e5695c2 Author: lana Date: 2010-03-04 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c2d29e5695c2 Merge Changeset: 58b44ac0b10d Author: ohair Date: 2010-03-06 14:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/58b44ac0b10d 6915983: testing problems, adjusting list of tests, needs some investigation Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt Changeset: eae6e9ab2606 Author: lana Date: 2010-03-09 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eae6e9ab2606 Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: 2cafbbe9825e Author: mikejwre Date: 2010-03-18 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/2cafbbe9825e Added tag jdk7-b86 for changeset eae6e9ab2606 ! .hgtags From john.coomes at sun.com Fri Mar 19 02:02:56 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 09:02:56 +0000 Subject: hg: jdk7/hotspot/langtools: 19 new changesets Message-ID: <20100319090356.AC0B344207@hg.openjdk.java.net> Changeset: 6eca0895a644 Author: jjg Date: 2010-02-23 18:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6eca0895a644 6511613: javac unexpectedly doesn't fail in some cases if an annotation processor specified Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/processing/6511613/DummyProcessor.java + test/tools/javac/processing/6511613/clss41701.java Changeset: 87eb6edd4f21 Author: jjg Date: 2010-02-25 09:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/87eb6edd4f21 4880220: Add a warning when accessing a static method via an reference Reviewed-by: darcy ! make/build.properties ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/4880220/T4880220.empty.out + test/tools/javac/4880220/T4880220.error.out + test/tools/javac/4880220/T4880220.java + test/tools/javac/4880220/T4880220.warn.out Changeset: 85242c273d31 Author: darcy Date: 2010-02-25 11:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/85242c273d31 6929645: Address various findbugs warnings in langtools Reviewed-by: jjg ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: dbcba45123cd Author: jjg Date: 2010-02-25 12:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/dbcba45123cd 6929544: langtools source code uses statics qualified by instance variables Reviewed-by: darcy ! make/build.properties ! src/share/classes/com/sun/tools/apt/main/CommandLine.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java ! src/share/classes/com/sun/tools/doclets/standard/Standard.java ! src/share/classes/com/sun/tools/javac/Launcher.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/CommandLine.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: af75fd6155de Author: jjg Date: 2010-02-25 13:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/af75fd6155de 6893943: exit code from javah with no args is 0 Reviewed-by: darcy ! src/share/classes/com/sun/tools/javah/JavahTask.java + test/tools/javah/T6893943.java Changeset: b030706da5b4 Author: jjg Date: 2010-02-26 08:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b030706da5b4 6881645: Unchecked method call on a method declared inside anonymous inner causes javac to crash Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java + test/tools/javac/T6881645.java Changeset: 72833a8a6086 Author: jjg Date: 2010-02-26 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/72833a8a6086 6930076: "null" can incorrectly appear in error message compiler.err.error.reading.file Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 7b69c7083a97 Author: jjg Date: 2010-02-26 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7b69c7083a97 6930032: fix findbugs errors in com.sun.tools.javac.comp Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java Changeset: 7c23bbbe0dbd Author: darcy Date: 2010-03-02 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7c23bbbe0dbd 6931130: Remove unused AnnotationCollector code from JavacProcessingEnvironment Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: 6e1e2738c530 Author: jjg Date: 2010-03-02 16:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6e1e2738c530 6931482: minor findbugs fixes Reviewed-by: darcy ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java Changeset: 235135d61974 Author: jjg Date: 2010-03-02 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/235135d61974 6931127: strange test class files Reviewed-by: darcy ! test/tools/javac/annotations/neg/Constant.java ! test/tools/javac/generics/Casting.java ! test/tools/javac/generics/Casting3.java ! test/tools/javac/generics/Casting4.java ! test/tools/javac/generics/InnerInterface1.java ! test/tools/javac/generics/InnerInterface2.java ! test/tools/javac/generics/Multibound1.java ! test/tools/javac/generics/MultipleInheritance.java ! test/tools/javac/generics/NameOrder.java ! test/tools/javac/generics/PermuteBound.java ! test/tools/javac/generics/PrimitiveVariant.java Changeset: fc7132746501 Author: darcy Date: 2010-03-03 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/fc7132746501 6449781: TypeElement.getQualifiedName for anonymous classes returns null instead of an empty name Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/processing/model/element/TestAnonClassNames.java + test/tools/javac/processing/model/element/TestAnonSourceNames.java Changeset: 7f5db2e8b423 Author: jjg Date: 2010-03-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7f5db2e8b423 6931927: position issues with synthesized anonymous class Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/tree/TestAnnotatedAnonClass.java + test/tools/javac/tree/TreePosTest.java - test/tools/javac/treepostests/TreePosTest.java Changeset: 117c95448ab9 Author: jjg Date: 2010-03-03 19:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/117c95448ab9 6931126: jtreg tests not Windows friendly Reviewed-by: darcy ! test/tools/javac/ThrowsIntersection_1.java ! test/tools/javac/ThrowsIntersection_2.java ! test/tools/javac/ThrowsIntersection_3.java ! test/tools/javac/ThrowsIntersection_4.java ! test/tools/javac/generics/NameOrder.java Changeset: c55733ceed61 Author: lana Date: 2010-03-04 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c55733ceed61 Merge Changeset: a23282f17d0b Author: jjg Date: 2010-03-05 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a23282f17d0b 6930108: IllegalArgumentException in AbstractDiagnosticFormatter for tools/javac/api/TestJavacTaskScanner.jav Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/api/TestResolveError.java Changeset: a4f3b97c8028 Author: jjg Date: 2010-03-05 16:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a4f3b97c8028 Merge Changeset: ef07347428f2 Author: lana Date: 2010-03-09 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ef07347428f2 Merge - test/tools/javac/treepostests/TreePosTest.java Changeset: 409db93d19c0 Author: mikejwre Date: 2010-03-18 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/409db93d19c0 Added tag jdk7-b86 for changeset ef07347428f2 ! .hgtags From Coleen.Phillimore at Sun.COM Fri Mar 19 07:37:14 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Fri, 19 Mar 2010 10:37:14 -0400 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <41F5F646-677B-4505-9E4C-81134E94D1B5@fredhopper.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> <4BA1FAD6.8090508@redhat.com> <4BA26444.90609@sun.com> <41F5F646-677B-4505-9E4C-81134E94D1B5@fredhopper.com> Message-ID: <4BA38C1A.80001@sun.com> Great! Thanks for reporting and diagnosing this. I was a bit mystified because I thought I'd tested it, but after a while the VM just started getting "Bus error". Including java -version. Do the files stay open after the process has exited? Why did it do this? thanks, Coleen Andreas Kohn wrote: > > > On 18.03.2010, at 18:35, Coleen Phillimore - Sun Microsystems > > wrote: > >> >> I filed bug 6936168 and have a repository with 3 additional >> fcloses() in them for the returns after the file is opened. See: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6936168/ >> > > With this change everything seems to work properly again :) > > Thanks, > -- > Andreas >> >> Coleen >> >> On 03/18/10 06:05, Andrew Haley wrote: >>> On 03/18/2010 09:10 AM, Andreas Kohn wrote: >>> >>>> On Fri, 2010-03-12 at 09:44 +0000, Andrew Haley wrote: >>>> >>>>> On 03/11/2010 09:06 PM, Coleen Phillimore wrote: >>>>> >>>>>> I've added the test to the changeset and a script to run in our harness. >>>>>> >>>>>> Also in os_linux.cpp, I changed the SYS_gettid call to go through our >>>>>> os::Linux::gettid() because on at least one linux, syscall() returns a >>>>>> long int which gets a compilation warning with %d. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/6929067/ >>>>>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 >>>>>> >>>>>> Andrew, please have a look since you're the contributor. >>>>>> >>>>> That's OK, but you don't need SYS_gettid. >>>>> Please look at http://cr.openjdk.java.net/~aph/6929067-jdk7-webrev-4/hotspot.patch >>>>> I changed to "/proc/self/maps", as you requested. I think this is better. >>>>> >>>>> The copy of my webrev to cr.openjdk.java.net failed for some reason >>>>> I don't understand. >>>>> >>>> With this change I seem to hit the limit on the number of open files. >>>> Looking through it, shouldn't get_stack_bounds() close the FILE* it >>>> opened? >>>> >>> >>> Oh, how stupid of me! If this were gcc I'd just push a fix >>> immediately as obvious/trivial, but I think we need a bug opened to >>> push the change. >>> >>> (BTW, this happened because of a mistake translating the patch I wrote >>> from using the C++ library into C. The original patch used an >>> fstream, whose destructor closes the file. When I did the translation >>> I missed the fact that I had to close the file manually.) >>> >>> Andrew. >>> From aph at redhat.com Fri Mar 19 07:40:22 2010 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Mar 2010 14:40:22 +0000 Subject: Request for approval: 6929067: Stack guard pages should be removed when thread is detached In-Reply-To: <4BA38C1A.80001@sun.com> References: <4B83FF49.6060004@redhat.com> <17c6771e1002231115h28d0f281p5abff855ab1406c@mail.gmail.com> <4B843177.2030500@redhat.com> <17c6771e1002231236r517e57dp7fde6ff0b9110a31@mail.gmail.com> <4B8456BD.1000101@sun.com> <4B8FD88B.3050709@redhat.com> <4B9031BF.60909@sun.com> <4B90374D.4040806@sun.com> <4B9132BA.8050206@redhat.com> <4B913A1B.1060701@sun.com> <4B913E7F.8010803@sun.com> <4B914673.1090200@redhat.com> <4B9104AF.5010106@sun.com> <4B995B49.6060603@sun.com> <4B9A0CE6.7010504@redhat.com> <1268903438.6514.3.camel@tiamaria.ams.fredhopper.com> <4BA1FAD6.8090508@redhat.com> <4BA26444.90609@sun.com> <41F5F646-677B-4505-9E4C-81134E94D1B5@fredhopper.com> <4BA38C1A.80001@sun.com> Message-ID: <4BA38CD6.7090701@redhat.com> On 03/19/2010 02:37 PM, Coleen Phillimore wrote: > > Great! Thanks for reporting and diagnosing this. I was a bit mystified > because I thought I'd tested it, but after a while the VM just started > getting "Bus error". Including java -version. Do the files stay open > after the process has exited? No they don't, and in any case the pool of file handles is per-process. Also, the kernel closes all open files at process exit. > Why did it do this? Impossible to say. Andrew. From vladimir.kozlov at sun.com Fri Mar 19 14:00:55 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Fri, 19 Mar 2010 21:00:55 +0000 Subject: hg: hsx/hsx17/baseline: 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 Message-ID: <20100319210109.CF7C8442C5@hg.openjdk.java.net> Changeset: 13b5f241341a Author: kvn Date: 2010-03-19 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/13b5f241341a 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 Summary: Added missing counter decrement when substring search restarted. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp + test/compiler/6935535/Test.java From andrey.petrusenko at sun.com Mon Mar 22 10:20:37 2010 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Mon, 22 Mar 2010 17:20:37 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20100322172107.D2520446AB@hg.openjdk.java.net> Changeset: 2a1472c30599 Author: jcoomes Date: 2010-03-03 14:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2a1472c30599 4396719: Mark Sweep stack overflow on deeply nested Object arrays Summary: Use an explicit stack for object arrays and process them in chunks. Reviewed-by: iveresov, apetrusenko ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp + src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_gc_parallel ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp + src/share/vm/oops/objArrayKlass.inline.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 94946bdf36bd Author: apetrusenko Date: 2010-03-15 02:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/94946bdf36bd Merge Changeset: 664ae0c5e0e5 Author: johnc Date: 2010-03-11 11:44 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/664ae0c5e0e5 6755988: G1: assert(new_obj != 0 || ... "should be forwarded") Summary: A TLAB became large enough to be considered a humongous object allowing multiple objects to be allocated in a humongous region, which violates a basic assumption about humongous regions. The changes ensure that TLABs cannot be regarded as humongous. Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 3f0549ed0c98 Author: apetrusenko Date: 2010-03-18 01:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3f0549ed0c98 6921710: G1: assert(new_finger >= _finger && new_finger < _region_limit,"invariant") Summary: If CM task was aborted while scanning the last object of the specified region and the size of that object is equal to bitmap's granularity then the next offset would be equal or over the region limit which is exactly what the assertion states. Reviewed-by: ysr, tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: c385bf94cfb8 Author: jcoomes Date: 2010-03-18 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c385bf94cfb8 6935839: excessive marking stack growth during full gcs Summary: process one item at a time from the objarray stack/queue Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp Changeset: cc98cc548f51 Author: apetrusenko Date: 2010-03-22 02:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cc98cc548f51 Merge ! src/share/vm/includeDB_core ! src/share/vm/runtime/arguments.cpp From daniel.daugherty at sun.com Wed Mar 24 09:57:26 2010 From: daniel.daugherty at sun.com (daniel.daugherty at sun.com) Date: Wed, 24 Mar 2010 16:57:26 +0000 Subject: hg: hsx/hsx17/baseline: 2 new changesets Message-ID: <20100324165731.0C3A844181@hg.openjdk.java.net> Changeset: 4f7af0dc447b Author: dcubed Date: 2010-03-23 14:37 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/4f7af0dc447b 6915365: 3/4 assert(false,"Unsupported VMGlobal Type") at management.cpp:1540 Summary: Remove assert to decouple JDK and HotSpot additions of known types. Reviewed-by: mchung ! src/share/vm/services/management.cpp Changeset: 1e887eabb2b9 Author: dcubed Date: 2010-03-24 08:15 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/1e887eabb2b9 Merge From antonios.printezis at sun.com Thu Mar 25 09:22:12 2010 From: antonios.printezis at sun.com (antonios.printezis at sun.com) Date: Thu, 25 Mar 2010 16:22:12 +0000 Subject: hg: hsx/hsx17/baseline: 6935821: G1: threads created during marking do not active their SATB queues Message-ID: <20100325162218.DFF93442F1@hg.openjdk.java.net> Changeset: 6a778ef9ee4f Author: tonyp Date: 2010-03-18 12:14 -0400 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/6a778ef9ee4f 6935821: G1: threads created during marking do not active their SATB queues Summary: Newly-created threads always had the active field of their SATB queue initialized to false, even if they were created during marking. As a result, updates from threads created during a marking cycle were never enqueued and never processed. The fix includes remaining a method from active() to is_active() for readability and naming consistency. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp From doko at ubuntu.com Thu Mar 25 09:53:22 2010 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 25 Mar 2010 17:53:22 +0100 Subject: [patch] correctly identify Ubuntu as the operating system in crash reports instead of "Debian" Message-ID: <4BAB9502.7090008@ubuntu.com> This is applied in the IcedTea builds; now submitted as https://bugs.openjdk.java.net/show_bug.cgi?id=100137 Proposing to apply this to 7 and 6. Matthias From erik.trimble at sun.com Thu Mar 25 18:51:47 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Fri, 26 Mar 2010 01:51:47 +0000 Subject: hg: hsx/hsx17/baseline: 6938342: Bump the HS17 build number to 12 Message-ID: <20100326015149.A04F044384@hg.openjdk.java.net> Changeset: bdf64657de2a Author: trims Date: 2010-03-25 18:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/bdf64657de2a 6938342: Bump the HS17 build number to 12 Summary: Update the HS17 build number to 12 Reviewed-by: jcoomes ! make/hotspot_version From erik.trimble at sun.com Thu Mar 25 18:53:51 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Fri, 26 Mar 2010 01:53:51 +0000 Subject: hg: hsx/hsx17/baseline: 2 new changesets Message-ID: <20100326015355.3EDC644385@hg.openjdk.java.net> Changeset: f1f9af4b8e4e Author: trims Date: 2010-03-09 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/f1f9af4b8e4e Added tag hs17-b11 for changeset 23decd59cae7 ! .hgtags Changeset: bc7a1618e099 Author: trims Date: 2010-03-25 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/bc7a1618e099 Merge From erik.trimble at sun.com Thu Mar 25 18:55:22 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Thu, 25 Mar 2010 18:55:22 -0700 Subject: hg: hsx/hsx17/baseline/src/closed: Added tag hs17-b11 for changeset 6b6b440a5ee1 Message-ID: <20100326015523.91BD61D1BA@closedjdk.sfbay.sun.com> Changeset: e3ee17559aef Author: trims Date: 2010-03-09 16:44 -0800 URL: http://closedjdk.sfbay/hsx/hsx17/baseline/src/closed/rev/e3ee17559aef Added tag hs17-b11 for changeset 6b6b440a5ee1 ! .hgtags From erik.trimble at sun.com Thu Mar 25 18:56:22 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Thu, 25 Mar 2010 18:56:22 -0700 Subject: hg: hsx/hsx17/baseline/test/closed: Added tag hs17-b11 for changeset 375ef3014af4 Message-ID: <20100326015623.CA76B1D1BB@closedjdk.sfbay.sun.com> Changeset: ef85c236bf46 Author: trims Date: 2010-03-09 16:45 -0800 URL: http://closedjdk.sfbay/hsx/hsx17/baseline/test/closed/rev/ef85c236bf46 Added tag hs17-b11 for changeset 375ef3014af4 ! .hgtags From erik.trimble at sun.com Thu Mar 25 22:29:49 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Fri, 26 Mar 2010 05:29:49 +0000 Subject: hg: hsx/hsx17/master: 10 new changesets Message-ID: <20100326053011.655F3443C9@hg.openjdk.java.net> Changeset: b8a8eafd038d Author: apetrusenko Date: 2010-03-08 04:07 -0800 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/b8a8eafd038d 6921710: G1: assert(new_finger >= _finger && new_finger < _region_limit,"invariant") Summary: If CM task was aborted while scanning the last object of the specified region and the size of that object is equal to bitmap's granularity then the next offset would be equal or over the region limit which is exactly what the assertion states. Reviewed-by: ysr, tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 34571037987c Author: johnc Date: 2010-03-11 11:44 -0800 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/34571037987c 6755988: G1: assert(new_obj != 0 || ... "should be forwarded") Summary: A TLAB became large enough to be considered a humongous object allowing multiple objects to be allocated in a humongous region, which violates a basic assumption about humongous regions. The changes ensure that TLABs cannot be regarded as humongous. Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 2cb394bd7f8f Author: kvn Date: 2010-03-16 15:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/2cb394bd7f8f 6935466: new CodeCache flushing code is not guarded by the flag Summary: Add missing guard. Reviewed-by: never ! src/share/vm/compiler/compileBroker.cpp Changeset: f3fb145b87ba Author: never Date: 2010-03-18 13:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/f3fb145b87ba 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp + test/compiler/6930043/Test6930043.java Changeset: 13b5f241341a Author: kvn Date: 2010-03-19 11:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/13b5f241341a 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 Summary: Added missing counter decrement when substring search restarted. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp + test/compiler/6935535/Test.java Changeset: 4f7af0dc447b Author: dcubed Date: 2010-03-23 14:37 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/4f7af0dc447b 6915365: 3/4 assert(false,"Unsupported VMGlobal Type") at management.cpp:1540 Summary: Remove assert to decouple JDK and HotSpot additions of known types. Reviewed-by: mchung ! src/share/vm/services/management.cpp Changeset: 1e887eabb2b9 Author: dcubed Date: 2010-03-24 08:15 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/1e887eabb2b9 Merge Changeset: 6a778ef9ee4f Author: tonyp Date: 2010-03-18 12:14 -0400 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/6a778ef9ee4f 6935821: G1: threads created during marking do not active their SATB queues Summary: Newly-created threads always had the active field of their SATB queue initialized to false, even if they were created during marking. As a result, updates from threads created during a marking cycle were never enqueued and never processed. The fix includes remaining a method from active() to is_active() for readability and naming consistency. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: bdf64657de2a Author: trims Date: 2010-03-25 18:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/bdf64657de2a 6938342: Bump the HS17 build number to 12 Summary: Update the HS17 build number to 12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: bc7a1618e099 Author: trims Date: 2010-03-25 18:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/bc7a1618e099 Merge From john.coomes at sun.com Fri Mar 26 01:34:53 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 08:34:53 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b87 for changeset 6b1069f53fbc Message-ID: <20100326083453.6D35C443F8@hg.openjdk.java.net> Changeset: 82135c848d5f Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/82135c848d5f Added tag jdk7-b87 for changeset 6b1069f53fbc ! .hgtags From john.coomes at sun.com Fri Mar 26 01:34:57 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 08:34:57 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b87 for changeset 09a41111a401 Message-ID: <20100326083502.44B3F443F9@hg.openjdk.java.net> Changeset: 39e14d2da687 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/39e14d2da687 Added tag jdk7-b87 for changeset 09a41111a401 ! .hgtags From john.coomes at sun.com Fri Mar 26 01:42:10 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 08:42:10 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b87 for changeset 8b493f1aa136 Message-ID: <20100326084210.CFF79443FD@hg.openjdk.java.net> Changeset: d8ebd1591003 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/d8ebd1591003 Added tag jdk7-b87 for changeset 8b493f1aa136 ! .hgtags From john.coomes at sun.com Fri Mar 26 01:42:15 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 08:42:15 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b87 for changeset 3febd6fab2ac Message-ID: <20100326084215.6C811443FE@hg.openjdk.java.net> Changeset: 8c666f8f3565 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/8c666f8f3565 Added tag jdk7-b87 for changeset 3febd6fab2ac ! .hgtags From john.coomes at sun.com Fri Mar 26 01:42:25 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 08:42:25 +0000 Subject: hg: jdk7/hotspot/jdk: Added tag jdk7-b87 for changeset 2cafbbe9825e Message-ID: <20100326084303.1E5D2443FF@hg.openjdk.java.net> Changeset: b3c69282f6d3 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b3c69282f6d3 Added tag jdk7-b87 for changeset 2cafbbe9825e ! .hgtags From john.coomes at sun.com Fri Mar 26 01:46:43 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 08:46:43 +0000 Subject: hg: jdk7/hotspot/langtools: Added tag jdk7-b87 for changeset 409db93d19c0 Message-ID: <20100326084651.AA0BC44401@hg.openjdk.java.net> Changeset: f9b5d4867a26 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/f9b5d4867a26 Added tag jdk7-b87 for changeset 409db93d19c0 ! .hgtags From Coleen.Phillimore at Sun.COM Fri Mar 26 15:11:09 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Fri, 26 Mar 2010 18:11:09 -0400 Subject: Please review 6938627: Make temporary directory use property java.io.tmpdir when specified Message-ID: <4BAD30FD.5090200@sun.com> Summary: Get java.io.tmpdir property in os::get_temp_directory() and call this instead of harcoding "/tmp". Don't assume trailing file_separator either. open webrev at http://cr.openjdk.java.net/~coleenp/6938627/ bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938627 Thanks, Coleen From schlosna at gmail.com Fri Mar 26 17:07:38 2010 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 26 Mar 2010 20:07:38 -0400 Subject: Please review 6938627: Make temporary directory use property java.io.tmpdir when specified In-Reply-To: <4BAD30FD.5090200@sun.com> References: <4BAD30FD.5090200@sun.com> Message-ID: Coleen, There seems to be a couple issues on line 469 of src/os/linux/vm/attachListener_linux.cpp: - It seems like there should be a slash in the format string to match the Solaris version. - The call to os::get_temp_directory() appears to be missing the 'y' at the end. src/os/linux/vm/attachListener_linux.cpp: 469 sprintf(fn, "%s.attach_pid%d", os::get_temp_director(), ^ ^^ 470 os::current_process_id()); src/os/solaris/vm/attachListener_solaris.cpp: 600 sprintf(fn, "%s/.attach_pid%d", os::get_temp_directory(), ^ ^^ 601 os::current_process_id()); Thanks, Dave On Mar 26, 2010, at 6:11 PM, Coleen Phillimore wrote: > Summary: Get java.io.tmpdir property in os::get_temp_directory() and call this instead of harcoding "/tmp". Don't assume trailing file_separator either. > > open webrev at http://cr.openjdk.java.net/~coleenp/6938627/ > bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938627 > > Thanks, > Coleen From Coleen.Phillimore at Sun.COM Sat Mar 27 11:05:23 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore) Date: Sat, 27 Mar 2010 14:05:23 -0400 Subject: Please review 6938627: Make temporary directory use property java.io.tmpdir when specified In-Reply-To: References: <4BAD30FD.5090200@sun.com> Message-ID: <4BAE48E3.8090200@sun.com> Sorry, I rushed out the review and skipped a step and didn't build on linux. Thanks for catching this. Coleen David Schlosnagle wrote: > Coleen, > > There seems to be a couple issues on line 469 of src/os/linux/vm/attachListener_linux.cpp: > - It seems like there should be a slash in the format string to match the Solaris version. > - The call to os::get_temp_directory() appears to be missing the 'y' at the end. > > src/os/linux/vm/attachListener_linux.cpp: > 469 sprintf(fn, "%s.attach_pid%d", os::get_temp_director(), > ^ ^^ > 470 os::current_process_id()); > > src/os/solaris/vm/attachListener_solaris.cpp: > 600 sprintf(fn, "%s/.attach_pid%d", os::get_temp_directory(), > ^ ^^ > 601 os::current_process_id()); > > Thanks, > Dave > > > On Mar 26, 2010, at 6:11 PM, Coleen Phillimore wrote: > > >> Summary: Get java.io.tmpdir property in os::get_temp_directory() and call this instead of harcoding "/tmp". Don't assume trailing file_separator either. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6938627/ >> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938627 >> >> Thanks, >> Coleen >> > > From andrey.petrusenko at sun.com Mon Mar 29 16:07:31 2010 From: andrey.petrusenko at sun.com (andrey.petrusenko at sun.com) Date: Mon, 29 Mar 2010 23:07:31 +0000 Subject: hg: jdk7/hotspot/hotspot: 6935821: G1: threads created during marking do not active their SATB queues Message-ID: <20100329230744.907C64491B@hg.openjdk.java.net> Changeset: d4197f8d516a Author: tonyp Date: 2010-03-18 12:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d4197f8d516a 6935821: G1: threads created during marking do not active their SATB queues Summary: Newly-created threads always had the active field of their SATB queue initialized to false, even if they were created during marking. As a result, updates from threads created during a marking cycle were never enqueued and never processed. The fix includes remaining a method from active() to is_active() for readability and naming consistency. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp From sits at nuix.com Mon Mar 29 17:14:35 2010 From: sits at nuix.com (David Sitsky) Date: Tue, 30 Mar 2010 11:14:35 +1100 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 Message-ID: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> Hi, I apologise in advance if posting here is not appropriate. Posting to the Sun's forums and submitting a bug report 5 weeks ago has generated no activity at all. We have a complex data processing application involving many threads that is both memory and I/O intensive. We recently upgraded our application to 1.6.0_18 from 1.6.0_16, and have found the application can crash after just a few minutes of processing on some data sets, with both the 32-bit and 64-bit version of the server JVM on Win64. Before this upgrade, the application can run solidly for many hours or days without issue. I noticed other people have reported similar findings in the forum post here: http://forums.sun.com/thread.jspa?threadID=5424728. Interestingly, the client VM was stable. I have attached the output from -verbose:gc and the crash file. Is there any interest from members on what we can do to get to the bottom of this? I am happy to run any diagnostics to find more information. -- Cheers, David Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com Fax: +61 2 9212 6902 -------------- next part -------------- [GC 59069K->38588K(69312K), 0.0024379 secs] [GC 63164K->45820K(70976K), 0.0022712 secs] [Full GC 45820K->30261K(82624K), 0.1194970 secs] [GC 54133K->31317K(79680K), 0.0013681 secs] [GC 54506K->31638K(80576K), 0.0163182 secs] [GC 54230K->35407K(79168K), 0.0018485 secs] [GC 57423K->35836K(79552K), 0.0071578 secs] [GC 57276K->35964K(76480K), 0.0021276 secs] [GC 56892K->35924K(78400K), 0.0475672 secs] [GC 56340K->35908K(79040K), 0.0168941 secs] [GC 56324K->35900K(83776K), 0.0546515 secs] [GC 61180K->35956K(83648K), 0.0225183 secs] [GC 61236K->36020K(88832K), 0.0943025 secs] [GC 66804K->36084K(88896K), 0.0039258 secs] [GC 66868K->36124K(94976K), 0.0050171 secs] [GC 73564K->36180K(95232K), 0.0044809 secs] [GC 73620K->36196K(102784K), 0.0010475 secs] [GC 81636K->36204K(102976K), 0.0101797 secs] [GC 81644K->36292K(112000K), 0.0035601 secs] [GC 91268K->36356K(112256K), 0.0058771 secs] [GC 91332K->36372K(122752K), 0.0075243 secs] [GC 102164K->36372K(122880K), 0.0051876 secs] [GC 102164K->36364K(135296K), 0.0113165 secs] [GC 114892K->36460K(135424K), 0.0030708 secs] [GC 114918K->36508K(149888K), 0.0091965 secs] [GC 129884K->36540K(150080K), 0.0011699 secs] [GC 129916K->36596K(167168K), 0.0079505 secs] [GC 147188K->36724K(167104K), 0.0046857 secs] [GC 147316K->36831K(161536K), 0.0151976 secs] [GC 142751K->49021K(157504K), 0.0027301 secs] [GC 150461K->49998K(153536K), 0.0009574 secs] [GC 147214K->49694K(148736K), 0.0012588 secs] [GC 142878K->49718K(144896K), 0.0017565 secs] [GC 139062K->49806K(141248K), 0.0008423 secs] [GC 135502K->49894K(137856K), 0.0013008 secs] [GC 132134K->49886K(134464K), 0.0009524 secs] [GC 128798K->49894K(131264K), 0.0008334 secs] [GC 125670K->49982K(128320K), 0.0009647 secs] [GC 122750K->50057K(125440K), 0.0010167 secs] [GC 119945K->50193K(122816K), 0.0010498 secs] [GC 117393K->50105K(120128K), 0.0011117 secs] [GC 114745K->50137K(118272K), 0.0042279 secs] [GC 112281K->50209K(115264K), 0.0043827 secs] [GC 109985K->50225K(113600K), 0.0032425 secs] [GC 107761K->50297K(110912K), 0.0015668 secs] [GC 105721K->50401K(109376K), 0.0009682 secs] [GC 103777K->50433K(107008K), 0.0054051 secs] [GC 101889K->50417K(116864K), 0.0501937 secs] [GC 111793K->50441K(128768K), 0.0296026 secs] [GC 123721K->50465K(142784K), 0.0033614 secs] [GC 137761K->50537K(159296K), 0.0044535 secs] [GC 154345K->50617K(177344K), 0.0045367 secs] [GC 172089K->50609K(179072K), 0.0061812 secs] [GC 173799K->50761K(179072K), 0.0009620 secs] [GC 174025K->50833K(200512K), 0.0009123 secs] [GC 195793K->50961K(201216K), 0.0009597 secs] [GC 196512K->51040K(194624K), 0.0026369 secs] [GC 190112K->51088K(188544K), 0.0011991 secs] [GC 184080K->51176K(182784K), 0.0046129 secs] [GC 178408K->51416K(177472K), 0.0009197 secs] [GC 173144K->51336K(172032K), 0.0011799 secs] [GC 167816K->51448K(167104K), 0.0058101 secs] [GC 162917K->51520K(162304K), 0.0046441 secs] [GC 158226K->51576K(157824K), 0.0011125 secs] [GC 153848K->51624K(153536K), 0.0011268 secs] [GC 149608K->51648K(149376K), 0.0030973 secs] [GC 145536K->51736K(145536K), 0.0042268 secs] [GC 141720K->51784K(141824K), 0.0011452 secs] [GC 138056K->51920K(138368K), 0.0009582 secs] [GC 134672K->51880K(134912K), 0.0042634 secs] [GC 131304K->51848K(149056K), 0.0166843 secs] [GC 145480K->51952K(167808K), 0.3751325 secs] [GC 164137K->52182K(189824K), 0.0041902 secs] [GC 186390K->52214K(216000K), 0.0009254 secs] [GC 212662K->52358K(222656K), 0.0010336 secs] [GC 219348K->52414K(222784K), 0.0009978 secs] [GC 219454K->52462K(254720K), 0.0264748 secs] [GC 251566K->52502K(254784K), 0.0019502 secs] [GC 251606K->52702K(292032K), 0.0045078 secs] [GC 289118K->52806K(292416K), 0.0013543 secs] [GC 289528K->52884K(334592K), 0.0016538 secs] [GC 331924K->53100K(335296K), 0.0010856 secs] [GC 332652K->53324K(381888K), 0.0011991 secs] [GC 379468K->53244K(383040K), 0.0164641 secs] [GC 380476K->53452K(367424K), 0.0011017 secs] [GC 365260K->53668K(352832K), 0.0009420 secs] [GC 350820K->53804K(338880K), 0.0012646 secs] [GC 337004K->53927K(325568K), 0.0010925 secs] [GC 323879K->54047K(312960K), 0.0012511 secs] [GC 311391K->54215K(300992K), 0.0009739 secs] [GC 299591K->54295K(289600K), 0.0008969 secs] [GC 288279K->54495K(278848K), 0.0009320 secs] [GC 277663K->54597K(268544K), 0.0010351 secs] [GC 267525K->54821K(258880K), 0.0009046 secs] [GC 258021K->54829K(249472K), 0.0011121 secs] [GC 248749K->54893K(240704K), 0.0009743 secs] [GC 239981K->54989K(232448K), 0.0012534 secs] [GC 231772K->55188K(224512K), 0.0010802 secs] [GC 223956K->55164K(216768K), 0.0011968 secs] [GC 216380K->55396K(209728K), 0.0009632 secs] [GC 209444K->55404K(202816K), 0.0009832 secs] [Full GC 55404K->28314K(194880K), 0.1386292 secs] [GC 175514K->28506K(188352K), 0.0020306 secs] [GC 169242K->28650K(182272K), 0.0009863 secs] [GC 163242K->28634K(176320K), 0.0008823 secs] [GC 157339K->28811K(170816K), 0.0007622 secs] [GC 152014K->28913K(165440K), 0.0007549 secs] [GC 146737K->29009K(160448K), 0.0009424 secs] [GC 141777K->29057K(155584K), 0.0012869 secs] [GC 137025K->29041K(150976K), 0.0009147 secs] [GC 132465K->29177K(146944K), 0.0007568 secs] [GC 128250K->29306K(142592K), 0.0007526 secs] [GC 124218K->29258K(138624K), 0.0008492 secs] [GC 120266K->29394K(134976K), 0.0009555 secs] [GC 116690K->29442K(131392K), 0.0009200 secs] [GC 113154K->29482K(127936K), 0.0008080 secs] [GC 109802K->29498K(124736K), 0.0008315 secs] [GC 106618K->29650K(121728K), 0.0007537 secs] [GC 103698K->29634K(118720K), 0.0008939 secs] [GC 100738K->29674K(115968K), 0.0008839 secs] [GC 98026K->29690K(113344K), 0.0008604 secs] [GC 95418K->29818K(110912K), 0.0007668 secs] [GC 93128K->29920K(108416K), 0.0008134 secs] [GC 90720K->29960K(106112K), 0.0008196 secs] [GC 88456K->29968K(103936K), 0.0008138 secs] [GC 86288K->30048K(101888K), 0.0007899 secs] [GC 84320K->30120K(99968K), 0.0007437 secs] [GC 82408K->30136K(97984K), 0.0008939 secs] [GC 80504K->30176K(96192K), 0.0009016 secs] [GC 78752K->30256K(94528K), 0.0007179 secs] [GC 77104K->30264K(92800K), 0.0008038 secs] [GC 75473K->30278K(100736K), 0.0037217 secs] [GC 83462K->30414K(110016K), 0.0008650 secs] [GC 92814K->30414K(107648K), 0.0007599 secs] [GC 90500K->30525K(105408K), 0.0008442 secs] [GC 88317K->30565K(103232K), 0.0010602 secs] [GC 86181K->30637K(101184K), 0.0008103 secs] [GC 84205K->30677K(99264K), 0.0008723 secs] [GC 82325K->30733K(97408K), 0.0007714 secs] [GC 80525K->30741K(95616K), 0.0007934 secs] [GC 78738K->30845K(94016K), 0.0009197 secs] [GC 77181K->30797K(92288K), 0.0009666 secs] [GC 75533K->30909K(90816K), 0.0008835 secs] [GC 74109K->30957K(89344K), 0.0008615 secs] [GC 72685K->30933K(87872K), 0.0007149 secs] [GC 71253K->30997K(86592K), 0.0009431 secs] [GC 69973K->31037K(85312K), 0.0009901 secs] [GC 68763K->31147K(84096K), 0.0009478 secs] [GC 67627K->31259K(83008K), 0.0010186 secs] [GC 66587K->31219K(88960K), 0.0009289 secs] [GC 72627K->31323K(96128K), 0.0008850 secs] [GC 79835K->31371K(94400K), 0.0008873 secs] [GC 78155K->31387K(92736K), 0.0007722 secs] [GC 76507K->31419K(91200K), 0.0007853 secs] [GC 75003K->31491K(89728K), 0.0009308 secs] [GC 73603K->31547K(88320K), 0.0008469 secs] [GC 72251K->31635K(87040K), 0.0007607 secs] [GC 70995K->31531K(93888K), 0.0024325 secs] [GC 77867K->31699K(102144K), 0.0008935 secs] [GC 86163K->31699K(111488K), 0.0009647 secs] [GC 95572K->31764K(109056K), 0.0008742 secs] [GC 93204K->31788K(106752K), 0.0008465 secs] [GC 90924K->31796K(104448K), 0.0009054 secs] [GC 88695K->32002K(102400K), 0.0007684 secs] [GC 86786K->32058K(100416K), 0.0009150 secs] [GC 84858K->32106K(98496K), 0.0009481 secs] [GC 82986K->32122K(96640K), 0.0009543 secs] [GC 81146K->32138K(94848K), 0.0008958 secs] [GC 79434K->32250K(93248K), 0.0009093 secs] [GC 77882K->32314K(91712K), 0.0008111 secs] [GC 76346K->32290K(90112K), 0.0009655 secs] [GC 74786K->32370K(97856K), 0.0042272 secs] [GC 82610K->32426K(106880K), 0.0010937 secs] [GC 91690K->32434K(117376K), 0.0009424 secs] [GC 102194K->32514K(129408K), 0.0007945 secs] [GC 114306K->32530K(126144K), 0.0008588 secs] [GC 111058K->32634K(123008K), 0.0008600 secs] [GC 108026K->32618K(119936K), 0.0008496 secs] [GC 105002K->32666K(117120K), 0.0007953 secs] [GC 102234K->32778K(114496K), 0.0008742 secs] [GC 99658K->32850K(112000K), 0.0012946 secs] [GC 97170K->32794K(109440K), 0.0009004 secs] [GC 94682K->32842K(107072K), 0.0007799 secs] [GC 92362K->32986K(104960K), 0.0007734 secs] [GC 90266K->33002K(102784K), 0.0008569 secs] [GC 88170K->33018K(100736K), 0.0008072 secs] [GC 86138K->33058K(98816K), 0.0009096 secs] [GC 84258K->33098K(96960K), 0.0009343 secs] [GC 82442K->33170K(95232K), 0.0008950 secs] [GC 80786K->33202K(93568K), 0.0008076 secs] [GC 79154K->33202K(91968K), 0.0009685 secs] [GC 77554K->33210K(90368K), 0.0009389 secs] [GC 76026K->33322K(88960K), 0.0008219 secs] [GC 74666K->33394K(87616K), 0.0008889 secs] [GC 73330K->33370K(86208K), 0.0008457 secs] [GC 71962K->33346K(84864K), 0.0009100 secs] [GC 70658K->33514K(83776K), 0.0007711 secs] [GC 69610K->33522K(82560K), 0.0010178 secs] [GC 68466K->33490K(88512K), 0.0010756 secs] [GC 74450K->33594K(87232K), 0.0008438 secs] [GC 73210K->33570K(94144K), 0.0019721 secs] [GC 80162K->33570K(102976K), 0.0104357 secs] [GC 88994K->33738K(113472K), 0.0008758 secs] [GC 99530K->33754K(125504K), 0.0009127 secs] [GC 111642K->33802K(139904K), 0.0041725 secs] [GC 126090K->33834K(156608K), 0.0007976 secs] [GC 142826K->33882K(175872K), 0.0009439 secs] [GC 162217K->34057K(197888K), 0.0009019 secs] [GC 184407K->34287K(191296K), 0.0008604 secs] [GC 177854K->34391K(184960K), 0.0009743 secs] [GC 171671K->34407K(178880K), 0.0008273 secs] [GC 165671K->34551K(173248K), 0.0007530 secs] [GC 160197K->34621K(167744K), 0.0010082 secs] [GC 154749K->34693K(162560K), 0.0009874 secs] [GC 149637K->34797K(157632K), 0.0008669 secs] [GC 144744K->34901K(153024K), 0.0008477 secs] [GC 140245K->34957K(172928K), 0.0271042 secs] [GC 160269K->35093K(196352K), 0.0009478 secs] [GC 183708K->35205K(223552K), 0.0010309 secs] [GC 211077K->35213K(254912K), 0.0010794 secs] [GC 242509K->35429K(291008K), 0.0010459 secs] [GC 278771K->35515K(279616K), 0.0009497 secs] [GC 267515K->35635K(268992K), 0.0009385 secs] [GC 256947K->35755K(258816K), 0.0009096 secs] [GC 246891K->35843K(249152K), 0.0010263 secs] [GC 237394K->36138K(240064K), 0.0008611 secs] [GC 228458K->36146K(231232K), 0.0011641 secs] [GC 219762K->36362K(222976K), 0.0008569 secs] [GC 211658K->36322K(214976K), 0.0010790 secs] [GC 203746K->36498K(207616K), 0.0011075 secs] [GC 196380K->36594K(200512K), 0.0013377 secs] [GC 189426K->36706K(193728K), 0.0008939 secs] [GC 182754K->36818K(187264K), 0.0008423 secs] [GC 176402K->36858K(181056K), 0.0011572 secs] [GC 170298K->37002K(175296K), 0.0008846 secs] [GC 164560K->37034K(169728K), 0.0008738 secs] [GC 159225K->37273K(164544K), 0.0011318 secs] [GC 154215K->37375K(159488K), 0.0009501 secs] [GC 149247K->37455K(154752K), 0.0010825 secs] [GC 144591K->37527K(150208K), 0.0010078 secs] [GC 140119K->37567K(145920K), 0.0008584 secs] [GC 135871K->37711K(141888K), 0.0010016 secs] [GC 131919K->37711K(137920K), 0.0009535 secs] [GC 128015K->37799K(134208K), 0.0008735 secs] [GC 124391K->37855K(130688K), 0.0009693 secs] [GC 120927K->37951K(127424K), 0.0008777 secs] [GC 117695K->37951K(124160K), 0.0011156 secs] [GC 114495K->37967K(121024K), 0.0009505 secs] [GC 111439K->38095K(118208K), 0.0008823 secs] [GC 108687K->38151K(115456K), 0.0008430 secs] [GC 105991K->38215K(112832K), 0.0008781 secs] [GC 103431K->38263K(110336K), 0.0009250 secs] [GC 101061K->38365K(107968K), 0.0009597 secs] [GC 98717K->38445K(105728K), 0.0009100 secs] [GC 96557K->38509K(103616K), 0.0008022 secs] [GC 94445K->38525K(101504K), 0.0009377 secs] [GC 92413K->38549K(99520K), 0.0009566 secs] [GC 90453K->38637K(97664K), 0.0009670 secs] [GC 88685K->38661K(95872K), 0.0008885 secs] [GC 86917K->38669K(94080K), 0.0007795 secs] [GC 85197K->38773K(92544K), 0.0009716 secs] [GC 83701K->38701K(90944K), 0.0010906 secs] [GC 82093K->38845K(89536K), 0.0009089 secs] [GC 80765K->38909K(88128K), 0.0008581 secs] [GC 79421K->38949K(86784K), 0.0009008 secs] [GC 78117K->38997K(85504K), 0.0008600 secs] [GC 76885K->39037K(91968K), 0.0009751 secs] [GC 83390K->39046K(90432K), 0.0009000 secs] [GC 81862K->56954K(107392K), 0.0058682 secs] [Full GC 56954K->44555K(122880K), 0.1382204 secs] [GC 94667K->44715K(121024K), 0.0007872 secs] [GC 93099K->44811K(125952K), 0.0018847 secs] [GC 91531K->46497K(119488K), 0.0017708 secs] [GC 91581K->46625K(116544K), 0.0022658 secs] [GC 90273K->46672K(123712K), 0.0009297 secs] [GC 97630K->46789K(138432K), 0.0041094 secs] [GC 107077K->46925K(144320K), 0.0010528 secs] [GC 118285K->46909K(157248K), 0.0014690 secs] [GC 131261K->46958K(172352K), 0.0010178 secs] [GC 146414K->46934K(189824K), 0.0011964 secs] [GC# # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006dbe7a7f, pid=8720, t id=3344 # # JRE version: 6.0_18-b07 # Java VM: Java HotSpot(TM) 64-Bit Server VM (16.0-b13 mixed mode windows-amd64 ) # Problematic frame: # V [jvm.dll+0x3f7a7f] # # An error report file with more information is saved as: # C:\Users\mhoffman\AppData\Local\Nuix\Logs\20100329171259/crash.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # C:\Program Files\Nuix\Nuix Desktop> -------------- next part -------------- A non-text attachment was scrubbed... Name: crash.log Type: application/octet-stream Size: 28255 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100330/977afdbf/attachment-0001.obj From David.Holmes at oracle.com Mon Mar 29 17:24:24 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 30 Mar 2010 10:24:24 +1000 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> Message-ID: <4BB144B8.8060807@oracle.com> David, I can not see any open bug reports that match this issue. Did anyone even get a Review Id back from Sun when they submitted the bug report? Often with these bugs the GC is the victim, encountering an invalid oop that has been corrupted by other parts of the system. Unfortunately the site of the detection can be very far removed from the site of the corruption. A small reproducible test case is invaluable if it can be created. Cheers, David Holmes David Sitsky said the following on 03/30/10 10:14: > Hi, > > I apologise in advance if posting here is not appropriate. Posting to > the Sun's forums and submitting a bug report 5 weeks ago has generated > no activity at all. > > We have a complex data processing application involving many threads > that is both memory and I/O intensive. We recently upgraded our > application to 1.6.0_18 from 1.6.0_16, and have found the application > can crash after just a few minutes of processing on some data sets, > with both the 32-bit and 64-bit version of the server JVM on Win64. > Before this upgrade, the application can run solidly for many hours or > days without issue. > > I noticed other people have reported similar findings in the forum > post here: http://forums.sun.com/thread.jspa?threadID=5424728. > > Interestingly, the client VM was stable. > > I have attached the output from -verbose:gc and the crash file. Is > there any interest from members on what we can do to get to the bottom > of this? I am happy to run any diagnostics to find more information. > > From paul.hohensee at oracle.com Mon Mar 29 17:25:08 2010 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 29 Mar 2010 20:25:08 -0400 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> Message-ID: <4BB144E4.1030803@oracle.com> Assuming you're using the server jvm, try using -XX:-ReduceInitialCardMarks. Paul On 3/29/10 8:14 PM, David Sitsky wrote: > Hi, > > I apologise in advance if posting here is not appropriate. Posting to > the Sun's forums and submitting a bug report 5 weeks ago has generated > no activity at all. > > We have a complex data processing application involving many threads > that is both memory and I/O intensive. We recently upgraded our > application to 1.6.0_18 from 1.6.0_16, and have found the application > can crash after just a few minutes of processing on some data sets, > with both the 32-bit and 64-bit version of the server JVM on Win64. > Before this upgrade, the application can run solidly for many hours or > days without issue. > > I noticed other people have reported similar findings in the forum > post here: http://forums.sun.com/thread.jspa?threadID=5424728. > > Interestingly, the client VM was stable. > > I have attached the output from -verbose:gc and the crash file. Is > there any interest from members on what we can do to get to the bottom > of this? I am happy to run any diagnostics to find more information. > > From sits at nuix.com Mon Mar 29 17:33:04 2010 From: sits at nuix.com (David Sitsky) Date: Tue, 30 Mar 2010 11:33:04 +1100 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <4BB144B8.8060807@oracle.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> <4BB144B8.8060807@oracle.com> Message-ID: <1c4bf5541003291733x4daf504fp9218a8168624575e@mail.gmail.com> Hi David, Many thanks for your reply. > I can not see any open bug reports that match this issue. Did anyone even > get a Review Id back from Sun when they submitted the bug report? I got a review ID of 1724814, but have had no further correspondence. > Often with these bugs the GC is the victim, encountering an invalid oop that > has been corrupted by other parts of the system. Unfortunately the site of > the detection can be very far removed from the site of the corruption. > > A small reproducible test case is invaluable if it can be created. I know.. I wish it was possible, but given the complexity of our system, being able to create a unit test from it will be very hard. I am happy to try running any other diagnostics that might assist? -- Cheers, David From sits at nuix.com Mon Mar 29 17:33:47 2010 From: sits at nuix.com (David Sitsky) Date: Tue, 30 Mar 2010 11:33:47 +1100 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <4BB144E4.1030803@oracle.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> <4BB144E4.1030803@oracle.com> Message-ID: <1c4bf5541003291733n436da189pae395462e1e7d9d@mail.gmail.com> Hi Paul, On 30 March 2010 11:25, Paul Hohensee wrote: > Assuming you're using the server jvm, try using -XX:-ReduceInitialCardMarks. Many thanks for your message. I'll give this a try and will let you know how this goes. -- Cheers, David Nuix Pty Ltd Suite 79, 89 Jones St, Ultimo NSW 2007, Australia Ph: +61 2 9280 0699 Web: http://www.nuix.com Fax: +61 2 9212 6902 From sits at nuix.com Mon Mar 29 21:00:58 2010 From: sits at nuix.com (David Sitsky) Date: Tue, 30 Mar 2010 15:00:58 +1100 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <1c4bf5541003291733n436da189pae395462e1e7d9d@mail.gmail.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> <4BB144E4.1030803@oracle.com> <1c4bf5541003291733n436da189pae395462e1e7d9d@mail.gmail.com> Message-ID: <1c4bf5541003292100w4ab74a3n95917925ccf306da@mail.gmail.com> > On 30 March 2010 11:25, Paul Hohensee wrote: >> Assuming you're using the server jvm, try using -XX:-ReduceInitialCardMarks. > > Many thanks for your message. ?I'll give this a try and will let you > know how this goes. That did indeed seem to fix the issue. Many thanks for your help. I can see searching for this flag quite a few other people have been hit by this issue with 1.6.0_18. Are there any bad side-effects in specifying -XX:-ReduceInitialCardMarks for production code? Does anyone know if there will be a 1.6.0_19 release with this issue fixed so a flag doesn't need to be specified? Cheers, David From David.Holmes at oracle.com Mon Mar 29 21:43:13 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 30 Mar 2010 14:43:13 +1000 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <1c4bf5541003292100w4ab74a3n95917925ccf306da@mail.gmail.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> <4BB144E4.1030803@oracle.com> <1c4bf5541003291733n436da189pae395462e1e7d9d@mail.gmail.com> <1c4bf5541003292100w4ab74a3n95917925ccf306da@mail.gmail.com> Message-ID: <4BB18161.2000300@oracle.com> David, David Sitsky said the following on 03/30/10 14:00: >> On 30 March 2010 11:25, Paul Hohensee wrote: >>> Assuming you're using the server jvm, try using -XX:-ReduceInitialCardMarks. >> Many thanks for your message. I'll give this a try and will let you >> know how this goes. > > That did indeed seem to fix the issue. Many thanks for your help. I > can see searching for this flag quite a few other people have been hit > by this issue with 1.6.0_18. > > Are there any bad side-effects in specifying > -XX:-ReduceInitialCardMarks for production code? > > Does anyone know if there will be a 1.6.0_19 release with this issue > fixed so a flag doesn't need to be specified? 6u19 is already announced: http://blogs.sun.com/security/category/news but I can't comment on whether this issue might already have been addressed, and if not when it might be addressed. David Holmes > Cheers, > David From sits at nuix.com Mon Mar 29 21:47:35 2010 From: sits at nuix.com (David Sitsky) Date: Tue, 30 Mar 2010 15:47:35 +1100 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <4BB18161.2000300@oracle.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> <4BB144E4.1030803@oracle.com> <1c4bf5541003291733n436da189pae395462e1e7d9d@mail.gmail.com> <1c4bf5541003292100w4ab74a3n95917925ccf306da@mail.gmail.com> <4BB18161.2000300@oracle.com> Message-ID: <1c4bf5541003292147m1269a707g3d90d608e383d2ec@mail.gmail.com> >> Does anyone know if there will be a 1.6.0_19 release with this issue >> fixed so a flag doesn't need to be specified? > > 6u19 is already announced: > > http://blogs.sun.com/security/category/news > > but I can't comment on whether this issue might already have been addressed, > and if not when it might be addressed. I guess we'll wait and see and check the release notes.. hopefully it will be mentioned in there, as I couldn't find a public bug record for this. Cheers, David From David.Holmes at oracle.com Mon Mar 29 23:02:32 2010 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 30 Mar 2010 16:02:32 +1000 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <1c4bf5541003292147m1269a707g3d90d608e383d2ec@mail.gmail.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> <4BB144E4.1030803@oracle.com> <1c4bf5541003291733n436da189pae395462e1e7d9d@mail.gmail.com> <1c4bf5541003292100w4ab74a3n95917925ccf306da@mail.gmail.com> <4BB18161.2000300@oracle.com> <1c4bf5541003292147m1269a707g3d90d608e383d2ec@mail.gmail.com> Message-ID: <4BB193F8.60606@oracle.com> David Sitsky said the following on 03/30/10 14:47: >>> Does anyone know if there will be a 1.6.0_19 release with this issue >>> fixed so a flag doesn't need to be specified? >> 6u19 is already announced: >> >> http://blogs.sun.com/security/category/news >> >> but I can't comment on whether this issue might already have been addressed, >> and if not when it might be addressed. > > I guess we'll wait and see and check the release notes.. hopefully it > will be mentioned in there, as I couldn't find a public bug record for > this. I just found it: 6896647 Fixed in 6u19 and 6u20 David Holmes From sits at nuix.com Mon Mar 29 23:14:07 2010 From: sits at nuix.com (David Sitsky) Date: Tue, 30 Mar 2010 17:14:07 +1100 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <4BB193F8.60606@oracle.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> <4BB144E4.1030803@oracle.com> <1c4bf5541003291733n436da189pae395462e1e7d9d@mail.gmail.com> <1c4bf5541003292100w4ab74a3n95917925ccf306da@mail.gmail.com> <4BB18161.2000300@oracle.com> <1c4bf5541003292147m1269a707g3d90d608e383d2ec@mail.gmail.com> <4BB193F8.60606@oracle.com> Message-ID: <1c4bf5541003292314w7aec0182o38cb150ae3d3a2b0@mail.gmail.com> On 30 March 2010 17:02, David Holmes wrote: > David Sitsky said the following on 03/30/10 14:47: >>>> >>>> Does anyone know if there will be a 1.6.0_19 release with this issue >>>> fixed so a flag doesn't need to be specified? >>> >>> 6u19 is already announced: >>> >>> http://blogs.sun.com/security/category/news >>> >>> but I can't comment on whether this issue might already have been >>> addressed, >>> and if not when it might be addressed. >> >> I guess we'll wait and see and check the release notes.. hopefully it >> will be mentioned in there, as I couldn't find a public bug record for >> this. > > I just found it: 6896647 > > Fixed in 6u19 and 6u20 Fantastic.. thanks so much for your help. We'll download it tomorrow when it is hopefully available. -- Cheers, David From sits at nuix.com Mon Mar 29 23:30:10 2010 From: sits at nuix.com (David Sitsky) Date: Tue, 30 Mar 2010 17:30:10 +1100 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <4BB19698.9000901@oracle.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> <4BB144E4.1030803@oracle.com> <1c4bf5541003291733n436da189pae395462e1e7d9d@mail.gmail.com> <1c4bf5541003292100w4ab74a3n95917925ccf306da@mail.gmail.com> <4BB18161.2000300@oracle.com> <1c4bf5541003292147m1269a707g3d90d608e383d2ec@mail.gmail.com> <4BB193F8.60606@oracle.com> <4BB19698.9000901@oracle.com> Message-ID: <1c4bf5541003292330s1a881345w58b0d261480b99e3@mail.gmail.com> On 30 March 2010 17:13, Y. Srinivas Ramakrishna wrote: > Right and, for the record, this bug was release-noted in 6u18 as well. True.. and in the future I'll certainly check that section in the future to read the "fine print". I think it was perhaps a bit questionable to release 1.6.0_18 in this state where a default install is exposed to this nasty issue, when -XX:-ReduceInitialCardMarks could have been specified by default for the GC collectors affected, but anyway, that is just me. Lots of people upgrade to the latest JDK without reading the release notes, rightly or wrongly. That said, I realise these things are not black and white, so I am sure there were reasons behind this. Thanks again to everyone for the prompt help. Cheers, David From y.s.ramakrishna at oracle.com Mon Mar 29 23:13:44 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Mon, 29 Mar 2010 23:13:44 -0700 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <4BB193F8.60606@oracle.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> <4BB144E4.1030803@oracle.com> <1c4bf5541003291733n436da189pae395462e1e7d9d@mail.gmail.com> <1c4bf5541003292100w4ab74a3n95917925ccf306da@mail.gmail.com> <4BB18161.2000300@oracle.com> <1c4bf5541003292147m1269a707g3d90d608e383d2ec@mail.gmail.com> <4BB193F8.60606@oracle.com> Message-ID: <4BB19698.9000901@oracle.com> Right and, for the record, this bug was release-noted in 6u18 as well. -- ramki David Holmes wrote: > David Sitsky said the following on 03/30/10 14:47: >>>> Does anyone know if there will be a 1.6.0_19 release with this issue >>>> fixed so a flag doesn't need to be specified? >>> 6u19 is already announced: >>> >>> http://blogs.sun.com/security/category/news >>> >>> but I can't comment on whether this issue might already have been >>> addressed, >>> and if not when it might be addressed. >> >> I guess we'll wait and see and check the release notes.. hopefully it >> will be mentioned in there, as I couldn't find a public bug record for >> this. > > I just found it: 6896647 > > Fixed in 6u19 and 6u20 > > David Holmes From Coleen.Phillimore at Sun.COM Tue Mar 30 14:45:47 2010 From: Coleen.Phillimore at Sun.COM (Coleen Phillimore - Sun Microsystems) Date: Tue, 30 Mar 2010 17:45:47 -0400 Subject: Please review 6938627: Make temporary directory use property java.io.tmpdir when specified In-Reply-To: References: <4BAD30FD.5090200@sun.com> Message-ID: <4BB2710B.1090102@sun.com> I've revised the /tmp directory code to protect against buffer overflows. I've also tested it on linux too. Please rereview this code. Summary: Get java.io.tmpdir property in os::get_temp_directory() and call this instead of harcoding "/tmp". Don't assume trailing file_separator either. local webrev at http://jruntime.east/~coleenp/webrev/6938627 bug link at http://monaco.sfbay.sun.com/detail.jsf?cr=6938627 Thanks, Coleen On 03/26/10 20:07, David Schlosnagle wrote: > Coleen, > > There seems to be a couple issues on line 469 of src/os/linux/vm/attachListener_linux.cpp: > - It seems like there should be a slash in the format string to match the Solaris version. > - The call to os::get_temp_directory() appears to be missing the 'y' at the end. > > src/os/linux/vm/attachListener_linux.cpp: > 469 sprintf(fn, "%s.attach_pid%d", os::get_temp_director(), > ^ ^^ > 470 os::current_process_id()); > > src/os/solaris/vm/attachListener_solaris.cpp: > 600 sprintf(fn, "%s/.attach_pid%d", os::get_temp_directory(), > ^ ^^ > 601 os::current_process_id()); > > Thanks, > Dave > > > On Mar 26, 2010, at 6:11 PM, Coleen Phillimore wrote: > > >> Summary: Get java.io.tmpdir property in os::get_temp_directory() and call this instead of harcoding "/tmp". Don't assume trailing file_separator either. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/6938627/ >> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938627 >> >> Thanks, >> Coleen >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100330/df4d977f/attachment.html From john.r.rose at oracle.com Tue Mar 30 15:00:17 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 30 Mar 2010 15:00:17 -0700 Subject: FYI: cross posted requests for review Message-ID: For JSR 292, I will be integrating more changes through the hotspot-comp subtree. As before, I have posted the requests for review to hotspot-compiler-dev. Here are the messages. To scope the discussion to one venue, please give review comments on the hotspot-compiler-dev list, if possible, or send them directly to me. Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2010-March/002953.html Request for reviews (M): 6939196: method handle signatures off the boot class path get linkage errors http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2010-March/002960.html Request for reviews (L): 6939207: refactor constant pool index processing http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2010-March/002965.html Request for reviews (L): 6939203: JSR 292 needs method handle constants http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2010-March/002961.html The change for 6939207 may be incomplete. I'd like advice on whether to push the change farther. I think we should perform byte swapping at the point where data is loaded (in the [Raw]BytecodeStream), because the byte order depends on the type of stream and is therefore known most accurately in the stream performing the fetching. But currently, we swap byte order in the CP accessors, which is many module boundaries away from the stream. See the temporary function 'get_index_native_swap' and the FIXME comments nearby; I'd like to get rid of get_index_native_swap. Is there a current reason why we can't tie byte swapping decisions to the type of bytecode stream? Thanks! -- John From David.Holmes at oracle.com Tue Mar 30 16:02:52 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 31 Mar 2010 09:02:52 +1000 Subject: Please review 6938627: Make temporary directory use property java.io.tmpdir when specified In-Reply-To: <4BB2710B.1090102@sun.com> References: <4BAD30FD.5090200@sun.com> <4BB2710B.1090102@sun.com> Message-ID: <4BB2831C.90803@oracle.com> Hi Coleen, This looks okay. The changes in ostream.cpp seem incidental to this CR though. Good catch on the buffer overflow issue, but more generally we need a CR to eliminate sprintf from the VM sources. David Coleen Phillimore - Sun Microsystems said the following on 03/31/10 07:45: > > I've revised the /tmp directory code to protect against buffer > overflows. I've also tested it on linux too. Please rereview this code. > > Summary: Get java.io.tmpdir property in os::get_temp_directory() and > call this instead of harcoding "/tmp". Don't assume trailing > file_separator either. > > local webrev at http://jruntime.east/~coleenp/webrev/6938627 > bug link at http://monaco.sfbay.sun.com/detail.jsf?cr=6938627 > > Thanks, > Coleen > > On 03/26/10 20:07, David Schlosnagle wrote: >> Coleen, >> >> There seems to be a couple issues on line 469 of src/os/linux/vm/attachListener_linux.cpp: >> - It seems like there should be a slash in the format string to match the Solaris version. >> - The call to os::get_temp_directory() appears to be missing the 'y' at the end. >> >> src/os/linux/vm/attachListener_linux.cpp: >> 469 sprintf(fn, "%s.attach_pid%d", os::get_temp_director(), >> ^ ^^ >> 470 os::current_process_id()); >> >> src/os/solaris/vm/attachListener_solaris.cpp: >> 600 sprintf(fn, "%s/.attach_pid%d", os::get_temp_directory(), >> ^ ^^ >> 601 os::current_process_id()); >> >> Thanks, >> Dave >> >> >> On Mar 26, 2010, at 6:11 PM, Coleen Phillimore wrote: >> >> >>> Summary: Get java.io.tmpdir property in os::get_temp_directory() and call this instead of harcoding "/tmp". Don't assume trailing file_separator either. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/6938627/ >>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938627 >>> >>> Thanks, >>> Coleen >>> >> >> From coleen.phillimore at oracle.com Wed Mar 31 08:07:19 2010 From: coleen.phillimore at oracle.com (Coleen Phillimore - Sun Microsystems) Date: Wed, 31 Mar 2010 11:07:19 -0400 Subject: Please review 6938627: Make temporary directory use property java.io.tmpdir when specified In-Reply-To: <4BB2831C.90803@oracle.com> References: <4BAD30FD.5090200@sun.com> <4BB2710B.1090102@sun.com> <4BB2831C.90803@oracle.com> Message-ID: <4BB36527.6090602@oracle.com> Thanks David. The ostream.cpp used the result of get_temp_directory() and didn't protect against string buffer overflow (which is unlikely given the buffer allocated was pretty large), but since I touched related code I had to fix this too. I completely agree we need a bug to search for and fix the remaining sprintfs and strcpy's that can overflow buffer sizes. Apparently there are 176. philli% ygrep sprintf | wc -l 176 Thanks! Coleen On 03/30/10 19:02, David Holmes wrote: > Hi Coleen, > > This looks okay. > > The changes in ostream.cpp seem incidental to this CR though. > > Good catch on the buffer overflow issue, but more generally we need a > CR to eliminate sprintf from the VM sources. > > David > > Coleen Phillimore - Sun Microsystems said the following on 03/31/10 > 07:45: >> >> I've revised the /tmp directory code to protect against buffer >> overflows. I've also tested it on linux too. Please rereview this >> code. >> >> Summary: Get java.io.tmpdir property in os::get_temp_directory() and >> call this instead of harcoding "/tmp". Don't assume trailing >> file_separator either. >> >> local webrev at http://jruntime.east/~coleenp/webrev/6938627 >> bug link at http://monaco.sfbay.sun.com/detail.jsf?cr=6938627 >> >> Thanks, >> Coleen >> >> On 03/26/10 20:07, David Schlosnagle wrote: >>> Coleen, >>> >>> There seems to be a couple issues on line 469 of >>> src/os/linux/vm/attachListener_linux.cpp: >>> - It seems like there should be a slash in the format string to >>> match the Solaris version. >>> - The call to os::get_temp_directory() appears to be missing the 'y' >>> at the end. >>> >>> src/os/linux/vm/attachListener_linux.cpp: >>> 469 sprintf(fn, "%s.attach_pid%d", os::get_temp_director(), >>> ^ ^^ >>> 470 os::current_process_id()); >>> >>> src/os/solaris/vm/attachListener_solaris.cpp: >>> 600 sprintf(fn, "%s/.attach_pid%d", os::get_temp_directory(), >>> ^ ^^ >>> 601 os::current_process_id()); >>> >>> Thanks, >>> Dave >>> >>> >>> On Mar 26, 2010, at 6:11 PM, Coleen Phillimore wrote: >>> >>> >>>> Summary: Get java.io.tmpdir property in os::get_temp_directory() >>>> and call this instead of harcoding "/tmp". Don't assume trailing >>>> file_separator either. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/6938627/ >>>> bug link at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6938627 >>>> >>>> Thanks, >>>> Coleen >>>> >>> >>> From erik.trimble at sun.com Wed Mar 31 15:26:54 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Wed, 31 Mar 2010 22:26:54 +0000 Subject: hg: hsx/hsx17/master: Added tag hs17-b12 for changeset bc7a1618e099 Message-ID: <20100331222701.6B64244BE6@hg.openjdk.java.net> Changeset: 59f7e0547288 Author: trims Date: 2010-03-31 15:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/59f7e0547288 Added tag hs17-b12 for changeset bc7a1618e099 ! .hgtags From erik.trimble at sun.com Wed Mar 31 15:28:00 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Wed, 31 Mar 2010 15:28:00 -0700 Subject: hg: hsx/hsx17/master/src/closed: Added tag hs17-b12 for changeset e3ee17559aef Message-ID: <20100331222801.0B21D1D20B@closedjdk.sfbay.sun.com> Changeset: 9c72c1d1bf55 Author: trims Date: 2010-03-31 15:26 -0700 URL: http://closedjdk.sfbay/hsx/hsx17/master/src/closed/rev/9c72c1d1bf55 Added tag hs17-b12 for changeset e3ee17559aef ! .hgtags From erik.trimble at sun.com Wed Mar 31 15:28:37 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Wed, 31 Mar 2010 15:28:37 -0700 Subject: hg: hsx/hsx17/master/test/closed: Added tag hs17-b12 for changeset ef85c236bf46 Message-ID: <20100331222838.8FB131D20C@closedjdk.sfbay.sun.com> Changeset: a9192b45b106 Author: trims Date: 2010-03-31 15:26 -0700 URL: http://closedjdk.sfbay/hsx/hsx17/master/test/closed/rev/a9192b45b106 Added tag hs17-b12 for changeset ef85c236bf46 ! .hgtags From erik.trimble at sun.com Wed Mar 31 15:40:00 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Wed, 31 Mar 2010 22:40:00 +0000 Subject: hg: hsx/hsx17/baseline: Added tag hs17-b12 for changeset bc7a1618e099 Message-ID: <20100331224003.109FC44BE9@hg.openjdk.java.net> Changeset: 59f7e0547288 Author: trims Date: 2010-03-31 15:26 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/59f7e0547288 Added tag hs17-b12 for changeset bc7a1618e099 ! .hgtags From erik.trimble at sun.com Wed Mar 31 15:41:26 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Wed, 31 Mar 2010 15:41:26 -0700 Subject: hg: hsx/hsx17/baseline/src/closed: Added tag hs17-b12 for changeset e3ee17559aef Message-ID: <20100331224127.412961D20D@closedjdk.sfbay.sun.com> Changeset: 9c72c1d1bf55 Author: trims Date: 2010-03-31 15:26 -0700 URL: http://closedjdk.sfbay/hsx/hsx17/baseline/src/closed/rev/9c72c1d1bf55 Added tag hs17-b12 for changeset e3ee17559aef ! .hgtags From erik.trimble at sun.com Wed Mar 31 15:42:04 2010 From: erik.trimble at sun.com (erik.trimble at sun.com) Date: Wed, 31 Mar 2010 15:42:04 -0700 Subject: hg: hsx/hsx17/baseline/test/closed: Added tag hs17-b12 for changeset ef85c236bf46 Message-ID: <20100331224205.8EA1B1D20E@closedjdk.sfbay.sun.com> Changeset: a9192b45b106 Author: trims Date: 2010-03-31 15:26 -0700 URL: http://closedjdk.sfbay/hsx/hsx17/baseline/test/closed/rev/a9192b45b106 Added tag hs17-b12 for changeset ef85c236bf46 ! .hgtags From erik.trimble at oracle.com Wed Mar 31 16:10:07 2010 From: erik.trimble at oracle.com (Erik Trimble) Date: Wed, 31 Mar 2010 16:10:07 -0700 Subject: Hotspot 17 Build 12 has been completed... Message-ID: <4BB3D64F.9020304@oracle.com> I've now pushed the complete contents of Hotspot 17 Build 12 out to the open repositories. This build will go into the Oracle JDK 6 Update 20 build 02. The tip for the build is: http://hg.openjdk.java.net/hsx/hsx17/master/rev/59f7e0547288 --------------- Component : VM Status : 0 major failures, 0 minor failures Date : 03/31/2010 at 01:40 Tested By : VM SQE Team and Leonid.Mesnik at sun.com Cost(total man-days): 1 Workspace : /java/jdk/6u20/ws/MASTER Bundles : /net/jprt-web/jprt/archive/2010/03/2010-03-26-015825.et151817.hs17b12 Platforms : Solaris Sparc 11(32), -client Solaris Sparc 11(32), -server Solaris Sparc 10(32), -client Solaris Sparc 10(32), -server Solaris x86 11(32), -client Solaris x86 11(32), -server Solaris x86 10(32), -client Solaris x86 10(32), -server WinXP Prof(32), -client WinXP Prof(32), -server WinXP Home(32), -client WinXP Home(32), -server Win Server 2003(32), -client Win Server 2003(32), -server Windows Vista 32 bit, -client Windows Vista 32 bit, -server Windows Vista 64 bit, -client Windows Vista 64 bit, -server RH AS4.0 (32), -client RH AS4.0 (32), -server SuSE SLES 8(32), -client SuSE SLES 8(32), -server Tests : /net/sqenfs-1.sfbay/export1/comp/vm/testbase Browsers : NA Patches : NA Logs : http://sqeweb.sfbay/nfs/results/vm/gtee/HSX/PIT/VM/17/b12/jdk6u20b02/ Number of Tests Executed : 274026 product tests, 0 unit tests, 0 tck tests Bug verification status: ====================================== Tested, Pass: 6755988: G1: assert(new_obj != 0 || ... "should be forwarded") 6921710: G1: assert(new_finger >= _finger && new_finger < _region_limit,"invariant") 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 Tested, Pass (partial fixes): Tested, Fail: Untested bug fixes: Setup is not available: 6915365: assert(false,"Unsupported VMGlobal Type") at management.cpp:1540 6935466: new CodeCache flushing code is not guarded by the flag 6935821: G1: threads created during marking do not active their SATB queues Build change only: 6938342: Bump the HS17 build number to 12 Other reasons: New bugs filed: Bugs in PIT build: Bugs in earlier promoted build: Number of PIT requested: 1 Integration target J2SE build number: 1.6.0_20-b02 Issues and Notes: This is HS 17 b12 PIT for JDK 1.6.0_20 b02 ------------------------------- >From VM SQE Team and Leonid.Mesnik at sun.com -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From y.s.ramakrishna at oracle.com Wed Mar 31 17:46:43 2010 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Wed, 31 Mar 2010 17:46:43 -0700 Subject: JVM crash with Server 1.6.0_18 (hotspot 16.0) on Win64 but not 1.6.0_16 In-Reply-To: <1c4bf5541003292330s1a881345w58b0d261480b99e3@mail.gmail.com> References: <1c4bf5541003291714y27052bb4odc7f0045e36e4f76@mail.gmail.com> <4BB144E4.1030803@oracle.com> <1c4bf5541003291733n436da189pae395462e1e7d9d@mail.gmail.com> <1c4bf5541003292100w4ab74a3n95917925ccf306da@mail.gmail.com> <4BB18161.2000300@oracle.com> <1c4bf5541003292147m1269a707g3d90d608e383d2ec@mail.gmail.com> <4BB193F8.60606@oracle.com> <4BB19698.9000901@oracle.com> <1c4bf5541003292330s1a881345w58b0d261480b99e3@mail.gmail.com> Message-ID: <4BB3ECF3.2010000@oracle.com> Yes, sorry, we should have done a better job of not letting that one slip through. We'll try and do better in the future. -- ramki On 03/29/10 23:30, David Sitsky wrote: > On 30 March 2010 17:13, Y. Srinivas Ramakrishna > wrote: >> Right and, for the record, this bug was release-noted in 6u18 as well. > > True.. and in the future I'll certainly check that section in the > future to read the "fine print". I think it was perhaps a bit > questionable to release 1.6.0_18 in this state where a default install > is exposed to this nasty issue, when -XX:-ReduceInitialCardMarks could > have been specified by default for the GC collectors affected, but > anyway, that is just me. > > Lots of people upgrade to the latest JDK without reading the release > notes, rightly or wrongly. That said, I realise these things are not > black and white, so I am sure there were reasons behind this. > > Thanks again to everyone for the prompt help. > > Cheers, > David