TraceTypeProfile as diagnostic option

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Sep 10 14:21:29 PDT 2012


Aleksey Shipilev wrote:
> Aha, are you suggesting this can jitter the memory footprint? Even if it
> does, then you have the problem with memory footprint jitter, not with
> the changes knocking you out of the beloved equilibrium.
> 
> I think you want these (in bytes)?
>  7418024 linux-baseline/j2re-image/lib/i386/client/libjvm.so
>  7418057 linux-tracetype/j2re-image/lib/i386/client/libjvm.so

You changed only C2 code which is only in Server VM. Different size could be 
caused by different length of build path ("linux-tracetype" vs "linux-baseline").

> 11706683 linux-baseline/j2re-image/lib/i386/server/libjvm.so
> 11706781 linux-tracetype/j2re-image/lib/i386/server/libjvm.so

Yes, this is what I would expect, about 100 bytes increase. But, please, try 
with the same build path length.

Vladimir

> 
> -Aleksey.
> 
> On 09/10/2012 11:52 PM, Vladimir Kozlov wrote:
>> The problem is not size on disk (yes it is also important) but memory
>> used by VM during execution. Also what VM sizes you got?
>>
>> Vladimir
>>
>> Aleksey Shipilev wrote:
>>> On 09/10/2012 10:28 PM, Vladimir Kozlov wrote:
>>>> Aleksey Shipilev wrote:
>>>>> On 09/10/2012 09:22 PM, Vladimir Kozlov wrote:
>>>>>> We need to be careful here. It will increase product VM size
>>>>>> (currently
>>>>>> that code is under #ifndef PRODUCT) and embedded group will kill us
>>>>>> for
>>>>>> that. I think we should look on this case by case. You still can
>>>>>> figure
>>>>>> out that it is bimorphic call since they have the same bci (@ 4).
>>>>> What is the reasonable increase in VM size we (they) could tolerate? I
>>>> None :) Seriously, they pushed several changes just to save few bytes in
>>>> our internal data structures.
>>>>
>>>>> can make the prototype change and figure out the actual increase. Looks
>>>>> like there is a single small printing subroutine and two calls.
>>>> The subroutine will be inlined in call sites so total size increase will
>>>> be bigger than one method. But increase may be disappear during linking
>>>> due to alignment, merge and other staff. So, please, do the experiment.
>>> There is unexpected trouble: PrintOpto and PrintOptoInlining symbols are
>>> not available in product scope, so I had to go an extra mile and stop
>>> referencing them (hence, the patch [1] is little dirty).
>>>
>>> Now, this is surprising:
>>>
>>> $ du -sk ...
>>> 108924    linux-baseline/j2re-image/
>>> 108916    linux-tracetype/j2re-image/
>>> 174476    linux-baseline/j2sdk-image/
>>> 174472    linux-tracetype/j2sdk-image/
>>>
>>> Hence, this seem to trim down the JDK size :)
>>>
>>> -Aleksey.
>>>
>>> [1]
>>>> diff -r cf0013b9698c src/share/vm/opto/doCall.cpp
>>>> --- a/src/share/vm/opto/doCall.cpp    Wed Sep 05 15:19:35 2012 -0700
>>>> +++ b/src/share/vm/opto/doCall.cpp    Mon Sep 10 23:37:25 2012 +0400
>>>> @@ -41,11 +41,10 @@
>>>>  #include "prims/nativeLookup.hpp"
>>>>  #include "runtime/sharedRuntime.hpp"
>>>>  
>>>> -#ifndef PRODUCT
>>>>  void trace_type_profile(ciMethod *method, int depth, int bci,
>>>> ciMethod *prof_method, ciKlass *prof_klass, int site_count, int
>>>> receiver_count) {
>>>> -  if (TraceTypeProfile || PrintInlining || PrintOptoInlining) {
>>>> +  if (TraceTypeProfile || PrintInlining) {
>>>>      if (!PrintInlining) {
>>>> -      if (!PrintOpto && !PrintCompilation) {
>>>> +      if (!PrintCompilation) {
>>>>          method->print_short_name();
>>>>          tty->cr();
>>>>        }
>>>> @@ -57,7 +56,6 @@
>>>>      tty->cr();
>>>>    }
>>>>  }
>>>> -#endif
>>>>  
>>>>  CallGenerator* Compile::call_generator(ciMethod* call_method, int
>>>> vtable_index, bool call_is_virtual,
>>>>                                         JVMState* jvms, bool
>>>> allow_inline,
>>>> @@ -233,13 +231,13 @@
>>>>            }
>>>>            if (miss_cg != NULL) {
>>>>              if (next_hit_cg != NULL) {
>>>> -              NOT_PRODUCT(trace_type_profile(jvms->method(),
>>>> jvms->depth() - 1, jvms->bci(), next_receiver_method,
>>>> profile.receiver(1), site_count, profile.receiver_count(1)));
>>>> +              trace_type_profile(jvms->method(), jvms->depth() - 1,
>>>> jvms->bci(), next_receiver_method, profile.receiver(1), site_count,
>>>> profile.receiver_count(1));
>>>>                // We don't need to record dependency on a receiver
>>>> here and below.
>>>>                // Whenever we inline, the dependency is added by
>>>> Parse::Parse().
>>>>                miss_cg =
>>>> CallGenerator::for_predicted_call(profile.receiver(1), miss_cg,
>>>> next_hit_cg, PROB_MAX);
>>>>              }
>>>>              if (miss_cg != NULL) {
>>>> -              NOT_PRODUCT(trace_type_profile(jvms->method(),
>>>> jvms->depth() - 1, jvms->bci(), receiver_method, profile.receiver(0),
>>>> site_count, receiver_count));
>>>> +              trace_type_profile(jvms->method(), jvms->depth() - 1,
>>>> jvms->bci(), receiver_method, profile.receiver(0), site_count,
>>>> receiver_count);
>>>>                CallGenerator* cg =
>>>> CallGenerator::for_predicted_call(profile.receiver(0), miss_cg,
>>>> hit_cg, profile.receiver_prob(0));
>>>>                if (cg != NULL)  return cg;
>>>>              }
>>>> diff -r cf0013b9698c src/share/vm/runtime/globals.hpp
>>>> --- a/src/share/vm/runtime/globals.hpp    Wed Sep 05 15:19:35 2012 -0700
>>>> +++ b/src/share/vm/runtime/globals.hpp    Mon Sep 10 23:37:25 2012 +0400
>>>> @@ -2894,7 +2894,7 @@
>>>>    develop(bool, TraceFrequencyInlining,
>>>> false,                              \
>>>>            "Trace frequency based
>>>> inlining")                                 \
>>>>                                                                             
>>>> \
>>>> -  notproduct(bool, TraceTypeProfile,
>>>> false,                                 \
>>>> +  diagnostic(bool, TraceTypeProfile,
>>>> false,                                 \
>>>>            "Trace type
>>>> profile")                                             \
>>>>                                                                             
>>>> \
>>>>    develop_pd(bool,
>>>> InlineIntrinsics,                                        \
>>>
> 


More information about the hotspot-compiler-dev mailing list