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.me...@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
