Perhaps I should throw an ExceptionInInitializerError w a CompileTheWorld
message?
--mm
On May 16, 2013, at 6:02 PM, John Rose <[email protected]> wrote:
> On May 15, 2013, at 4:00 PM, Phil Race <[email protected]> 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
