<AWT Dev> RFR(XS): 7196866: CTW fails on Solaris

[Phil Race]

To know whether the fix is appropriate or maybe the best fix,
I'd have to see what classes are loaded in what order.
I can see the JBS bug (external folks can't) but its not really
worth seeing anyway as there's not much info in there :-
http://bugs.sun.com/view_bug.do?bug_id=7196866
seems to contain all the data there is ..

I am still curious about the test envt. that triggered Xrender.

-phil.

On 5/15/13 4:40 PM, Vladimir Kozlov wrote:
> On 5/15/13 4:00 PM, Phil Race wrote:
>> It *initialises* all those classes ? Meaning their static initialisers
>> might run, call native methods in a library which expect things to have
>> been done in a different order ? Maybe the library isn't even loaded 
>> yet?
>> I presume this must be happening else we wouldn't be in this code.
>
> Yes, it is the case.
>
>> That's a somewhat fragile test. I guess it doesn't have to be involve
>> either.
>> Its good to know that "all classes compile" but I'm not sure I
>> can be easily convinced that its worth trying the wac-a-mole game
>> needed to ensure that this doesn't collide with the semantics
>> of the runtime, particularly in the client area which has lots of
>> native code and state. Plus anyone looking at changes to
>
> I agree, but fortunately it is only the second problem with such 
> conflict. First one was 7017493 ConcurrentLinkedDeque: Unexpected 
> initialization order. Which was fixed in java code.
>
>> accomodate this out of the context of the changes might be
>> puzzled as to why this is needed. In this case its 'defensive'
>> coding so maybe they won't think too long about it but still ..
>
> It is very simple changes which will help JVM important testing. The 
> only other solution for VM is to exclude these .jar files from testing 
> which we would like to avoid.
>
>> I see there are several linked bugs. I haven't looked but since
>> they appear in different areas I suppose this isn't the only case
>> although they appear relatively few in the scheme of things.
>> Can't compilation be done in some special fashion that bypasses
>> class initialisation ?
>
> No, we can't bypass class initialization since JIT compilation depends 
> on state of classes.
>
> thanks,
> Vladimir
>
>>
>> -phil.
>>
>> On 5/15/13 3:50 PM, Vladimir Kozlov wrote:
>>> Morris,
>>>
>>> Please, add to the bug report the command line and machines you used
>>> to reproduce the problem.
>>>
>>> Phil, the problem is triggered during special mode testing in JVM
>>> -XX:+CompileTheWorld. In this more JVM loads all classes in specified
>>> .jar file and compiles (JIT compilation) all methods in class. It is
>>> stress test for Hotspot JIT compilers. For such tests we don't set
>>> DISPLAY.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/15/13 3:27 PM, Phil Race wrote:
>>>> CC (instead of BCC) 2d-dev ..
>>>>
>>>> -phil.
>>>>
>>>> On 5/15/13 3:21 PM, Phil Race wrote:
>>>>> Morris,
>>>>>
>>>>> I traced this review back to hotspot-compiler-dev
>>>>> Thanks to Vladimir and Christian for the ponter to redirect but
>>>>> this should really go to 2d-dev not awt-dev.
>>>>> Xrender is the 2D pipeline for accelerated rendering on recent
>>>>> Xservers.
>>>>> Also it I think it should be pushed via the 2D forest after review,
>>>>> whereas it appears your webrev is against the hotspot forest.
>>>>> If the display is NULL we should not enter Xrender but operate in
>>>>> headless mode. So I'd like to take a closer look at this.
>>>>> Where did you test this ? Solaris 10 doesn't trigger xrender ?
>>>>> Did you actually use Solaris 11 on SPARC as the client *and* 
>>>>> Xserver ?
>>>>> Is there a regression test ?
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 5/15/13 2:57 PM, Christian Thalinger wrote:
>>>>>> Looks good.  Nit:  why is there an empty line?
>>>>>>
>>>>>> +    jlong fmt8;
>>>>>> +
>>>>>> +    jlong fmt32;
>>>>>>
>>>>>> -- Chris
>>>>>>
>>>>>> On May 15, 2013, at 1:21 PM, Morris Meyer <morris.meyer at oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> Could I get a review for these two small changes in
>>>>>>> src/solaris/native.  This is to fix the nightly CTW testing crashes
>>>>>>> on Solaris caused by a library SEGV internal to X11 that occurs
>>>>>>> during class initialization when the display is NULL.
>>>>>>>
>>>>>>> I've tested this patch on SfBay with JPRT and with the CTW tests on
>>>>>>> Solaris x86 and Sparc.
>>>>>>>
>>>>>>> Thanks much,
>>>>>>>
>>>>>>>         --morris
>>>>>>>
>>>>>>> JBS - https://jbs.oracle.com/bugs/browse/JDK-7196866
>>>>>>> WEBREV - http://cr.openjdk.java.net/~morris/7196866
>>>>>
>>>>
>>