> On 10 nov 2014, at 15:55, Aleksey Shipilev <aleksey.shipi...@oracle.com> > wrote: > > Hi Staffan, > > Ow, it seems very like it. > So, what testlist have I missed to catch this?
Probably vm.tmtools.testlist and/or nsk.sajdi.testlist. Just a warning that these tests are far from stable. Sorry about that. /Staffan > > -Aleksey. > > On 11/10/2014 05:51 PM, Staffan Larsen wrote: >> I’m afraid this change requires changes in the Serviceability Agent as well. >> See OopUtilities.threadOopGetName() for example. >> >> /Staffan >> >>> On 10 nov 2014, at 15:19, Aleksey Shipilev <aleksey.shipi...@oracle.com> >>> wrote: >>> >>> Hi David, Chris, >>> >>> On 11/10/2014 04:53 PM, Chris Hegarty wrote: >>>> On 10/11/14 12:56, David Holmes wrote: >>>>> On 10/11/2014 9:52 PM, Chris Hegarty wrote: >>>>>> I have only looked at the libraries changes, and I think they make sense >>>>>> . As in, I can find no reason why the name cannot be changed to be a >>>>>> String. >>>>> >>>>> Very quick response, but IIRC this has been examined in the past and >>>>> there were reasons why it can't/shouldn't be done. Will try to dig out >>>>> more details in the morning. >>>> >>>> If there was previous discussion on this, that revealed some substantial >>>> issue, that would be great, but I can't recall, or find, it now. >>>> >>>> Hotspot express, and the desire for hotspot to run with different >>>> library versions, would certainly cause complication, but I don't >>>> believe that is an issue now. >>>> >>>> Just on that, the library changes are minimal, and if this were to >>>> proceed then they can accompany the hotspot change, as they make their >>>> way into jdk9/dev. >>>> >>>> Anyway, this should await your reply. >>> >>> Alan was having the same concern, there is an issue with JNI/JVMTI and >>> other power users that might break when exposed to under-constructed >>> Thread, e.g: >>> https://bugs.openjdk.java.net/browse/JDK-6412693 >>> >>> This is why I ran jvmti and serviceability tests for this change, >>> yielding no failures. This reinforces my belief this patch does not >>> break the important invariant: if there is a problem with "Thread.name = >>> name.toCharArray()" anywhere in Thread code, then "Thread.name = name" >>> does neither regress it further nor fixes it. >>> >>> Then I speculated that having char[] name would help VM initialize the >>> name if we wanted to switch to complete VM-side initialization of >>> Thread, but it seems we can do String oop instantiation in the similar vein. >>> >>> Caching the name feels like a band-aid, that will probably complicate >>> the Thread initialization on VM side even more. Let's wait and see if >>> David can come up with some horror issue we are overlooking. :) >>> >>> Thanks, >>> -Aleksey. >>> >> > >
