TraceTypeProfile as diagnostic option (original) (raw)

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 tracetypeprofile(ciMethod *method, int depth, int bci, ciMethod *profmethod, ciKlass *profklass, int sitecount, int receivercount) { - if (TraceTypeProfile || PrintInlining || PrintOptoInlining) { + if (TraceTypeProfile || PrintInlining) { if (!PrintInlining) { - if (!PrintOpto && !PrintCompilation) { + if (!PrintCompilation) { method->printshortname(); tty->cr(); } @@ -57,7 +56,6 @@ tty->cr(); } } -#endif CallGenerator* Compile::callgenerator(ciMethod* callmethod, int vtableindex, bool callisvirtual, JVMState* jvms, bool allowinline, @@ -233,13 +231,13 @@ } if (misscg != NULL) { if (nexthitcg != NULL) { - NOTPRODUCT(tracetypeprofile(jvms->method(), jvms->depth() - 1, jvms->bci(), nextreceivermethod, profile.receiver(1), sitecount, profile.receivercount(1))); + tracetypeprofile(jvms->method(), jvms->depth() - 1, jvms->bci(), nextreceivermethod, profile.receiver(1), sitecount, profile.receivercount(1)); // We don't need to record dependency on a receiver here and below. // Whenever we inline, the dependency is added by Parse::Parse(). misscg = CallGenerator::forpredictedcall(profile.receiver(1), misscg, nexthitcg, PROBMAX); } if (misscg != NULL) { - NOTPRODUCT(tracetypeprofile(jvms->method(), jvms->depth() - 1, jvms->bci(), receivermethod, profile.receiver(0), sitecount, receivercount)); + tracetypeprofile(jvms->method(), jvms->depth() - 1, jvms->bci(), receivermethod, profile.receiver(0), sitecount, receivercount); CallGenerator* cg = CallGenerator::forpredictedcall(profile.receiver(0), misscg, hitcg, profile.receiverprob(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") _ __ developpd(bool, _InlineIntrinsics, _

More information about the hotspot-compiler-dev mailing list