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

[John Rose]

On May 15, 2013, at 4:00 PM, Phil Race <philip.race at oracle.com> 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.
> That's a somewhat fragile test.

Yes, it is.  And it requires a certain amount of ad hoc maintenance over the years.

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

Since the design of our stack has become more entangled (between JVM and JDK), it may be that this test is becoming harder to maintain.  But to date it has been very profitable, even with the maintenance costs like the present bug.

> ...Can't compilation be done in some special fashion that bypasses
> class initialisation ?

It's a fair question.  The short answer is "no", but the history is interesting, so I did some software archeology...

The CTW (CompileTheWorld) test mode dates back to August 1998, in the first days of the HotSpot implementation.  Since then it has continuously been a fruitful source of compiler bugs.  We use it every day for stress-testing compiler changes.

In the first few months of its implementation (through March 1999) we discovered that if you did not attempt to run class initializers on the classes, the resulting loaded code was so cold that compiling it was useless as a stress test.  For example, if a basic block has never been run, the compiler is sometimes lazy about compiling it, preferring to emit a deopt. path instead.  This means that anything that would have been inlined inside that basic block never gets looked at.  It's good for hot-spot-oriented compilation but bad for stress tests.

We found that preloading classes (CompileTheWorldPreloadClasses) and running class initializers (no special flag) caused the code to warm up enough that the compiler had something to work on that was more representative of typical inputs.  This greatly increased the value of the CTW stress test.

Native methods have always been a problem, of course.  I suppose we could do something to CTW mode to make it fail out of native method linkage in some packages.  That might also fix this problem, in a way that would not require hardening native code against the edge cases.

> anyone looking at changes to
> accomodate this out of the context of the changes might be
> puzzled as to why this is needed

In the end, native code hardening is surely a Good Thing, but I understand that puzzling changes like this can contribute to software rot.  Perhaps a simple comment like this would help:

  // CompileTheWorld gets here

— John