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