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

[Morris Meyer]

Phil,

This is the command line that generates the crash:

-XX:DefaultMaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -ea -esa 
-XX:+TieredCompilation -XX:CompileThreshold=100 
-XX:+UnlockExperimentalVMOptions -XX:-ShowMessageBoxOnError -Xverify:all 
-XX:+CompileTheWorld -XX:CompileTheWorldStartAt=15001 
-XX:CompileTheWorldStopAt=16000 -XX:LogFile=hotspot_15001_16000.log 
-XX:MaxPermSize=384M -Xmx512M -Xbootclasspath/p:jre/lib/rt.jar

To run the whole CTW suit - you just remove the StartAt and StopAt args.

I tested the Solaris x86 side of the world internally on sc14ia01, SPARC 
on sc11d1901.

         --mm

On 5/15/13 8:30 PM, Phil Race wrote:
> 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
>>>>>>
>>>>>
>>>
>