Turn off All Optimizations

[Krystal Mo]

Comments inline:

On 11/23/2012 02:43 PM, Xin Tong wrote:
> On Thu, Nov 22, 2012 at 2:11 PM, Krystal Mo <krystal.mo at oracle.com> wrote:
>> Hi Xin,
>>
>> So what you're looking for is some kind of baseline compiler, right?
>> How does your study relate to the ones on different threading techniques for
>> implementing interpreters? e.g. context-threading / inline-threading?
> I want to exam why interpreter is slower than the JIT. it is commonly
> believed (easily verifiable) that interpreter is typically much slower
> than the JIT. but no one ( at least i am not aware of) has ever fully
> investigated why. i want to look at the performance differences from a
> microarchitectural point of view., including the following
>
> 1. branch prediction
> 2. instruction cache
> 3. data cache
> 4. dynamic instruction count.
> 5. TLB.
>
> there may be more...
>
> different implementations of interpreters dohave impact on the
> results, but the context-threaded interpreter is believed to be more
> friendly than the simple switch based interpreter.
A compiler that doesn't do any optimizations is a baseline compiler. 
Inline-threaded interpreter is basically equivalent to a baseline 
interpreter; another similar form is "template-based compiler". These 
can be found in some JVM implementations (but not in HotSpot, though).

It looks like what you're trying to measure is the "interpretation 
overhead" of various forms of interpreters, comparing with a baseline 
that is "an interpreter with zero interpretation overhead, but no other 
optimizations applied".

>> Unfortunately neither C1 nor C2 has a magic switch to turn off all
>> optimizations. Turning code into SSA-form and back is already "optimizing"
>> in a lot of cases; both C1 and C2 use SSA-form intermediate representations,
>> so it wouldn't be reasonable to have such a magic switch.
>>
> I am modifying the opto compiler, trying to disable all the
> optimizations. however,  I think the       Node *nn =
> transform_old(n); in the PhaseIterGVN::optimize must be called for the
> compiler to work. does this transform the node to SSA representation
> which is later recognized by the code generator ?

The Ideal Graph in C2 is already an SSA-form IR. Java bytecode (which is 
not in SSA-form) is converted into Ideal Graph during parsing, which is 
very early in the compilation process; you can't disable it without 
effectively throwing away the core of C2. Iterative GVN is a later phase.

I'd imagine writing a new baseline compiler for HotSpot from scratch is 
easier than disabling all optimizations in C2 for your purpose.

> Are their any optimizations in the code generator as well, e.g. does
> hotspot run instruction scheduling ?
C2 does global code motion and peephole optimizations in the code generator.

- Kris

>
> Xin
>
>> If you're using the client VM, then you'd be using C1;
>> If you're using the server VM, and if tiered compilation is not turned on
>> (e.g. it's not turned on by default on JDK6 and JDK7 to date), then you'd be
>> using C2;
>> With tiered compilation, you'd be using both C1 and C2. A method could be
>> compiled multiple times by either compilers.
>>
>> - Kris
>>
>>
>> On 2012/11/23 1:18, Xin Tong wrote:
>>> I want the compiler to compile the code at the same time. i.e. i want
>>> to study why the compiler is so much faster than the intepreter from a
>>> microarchitectural point of view. enabling optimizations complicates
>>> the problem.
>>>
>>> there are 2 compilers in the hotspot, the c1 and opto. which one is used ?
>>>
>>> Xin
>>>
>>> On Thu, Nov 22, 2012 at 12:06 PM, Aleksey Shipilev
>>> <aleksey.shipilev at oracle.com>  wrote:
>>>> On 11/22/2012 09:00 PM, Xin Tong wrote:
>>>>> Is there a way to turn off all the optimizations the hotpot compiler
>>>>> will do to the bytecode when JITting it.
>>>> Use plain old interpreter with "-Xint"?
>>>>
>>>> -Aleksey.
>>>>