RFR(S): 8005885: enhance PrintCodeCache to print more data
Chris Plummer
chris.plummer at oracle.com
Tue Sep 3 23:21:05 PDT 2013
Hi Albert,
The reason for my request to itemize the buffer blobs was mainly to get
the generated interpreter size. I can also get that from
-XX:+PrintInterpreter, but that also dumps the entire interpreter. Also,
since each buffer blob is named, I figured there are likely cases were
getting more details on the allocated buffer blobs would be useful.
Anyway, this certainly is not a requirement for this round of changes,
just of a suggestion if it's not much bother.
thanks,
Chris
On 9/3/13 4:10 AM, Albert Noll wrote:
> Hi all,
>
> thanks again for the feedback.
> Here is the new webrev:
> http://cr.openjdk.java.net/~anoll/8005885/webrev.02/
> <http://cr.openjdk.java.net/%7Eanoll/8005885/webrev.02/>
>
> The changes are as follows:
>
>
> @Vladimir:
> I changed the parameters to size_t, since using a signed variable for
> a value that cannot become
> negative does not make sense. Also, the interface to the code cache
> uses size_t. E.g., capacity(), max_capacity(), etc.
> However, I did not consider the atomicity of increment, so I changed
> the types back to int.
>
> I now use the standard output of CodeBlob_sizes, so the output of a
> detailed print of the code cache
> looks as follows:
>
> Code cache entries: (total of #2265)
> nmethods: 1797# 76733 kB
> Java 1723# 6658 kB (hdr 7%, loc 6%, code 52%,
> stub 4%, [oops 0%, data 0%, pcs 9%])
> Tier 1 319# 283 kB (hdr 32%, loc 5%, code 29%,
> stub 20%, [oops 0%, data 0%, pcs 1%])
> Tier 2 79# 304 kB (hdr 7%, loc 8%, code 52%,
> stub 6%, [oops 0%, data 0%, pcs 8%])
> Tier 3 993# 4697 kB (hdr 6%, loc 7%, code 58%,
> stub 5%, [oops 0%, data 0%, pcs 8%])
> Tier 4 332# 1371 kB (hdr 6%, loc 3%, code 38%,
> stub 1%, [oops 0%, data 1%, pcs 16%])
> Native 74# 75 kB (hdr 28%, loc 10%, code 60%,
> stub 0%, [oops 0%, data 0%, pcs 0%])
> runtime stubs 59# 44 kB (hdr 9%, loc 6%, code 83%,
> stub 0%, [oops 0%, data 0%, pcs 0%])
> adapters 391# 302 kB (hdr 8%, loc 8%, code 81%,
> stub 0%, [oops 0%, data 0%, pcs 0%])
> buffer blobs 12# 1469 kB (hdr 0%, loc 0%, code 99%,
> stub 0%, [oops 0%, data 0%, pcs 0%])
> deoptimization stubs 1# 1 kB (hdr 5%, loc 2%, code 89%,
> stub 0%, [oops 0%, data 0%, pcs 0%])
> uncommon trap stubs 1# 0 kB (hdr 12%, loc 1%, code 83%,
> stub 0%, [oops 0%, data 0%, pcs 0%])
> others 4# 2 kB (hdr 12%, loc 1%, code 84%,
> stub 0%, [oops 0%, data 0%, pcs 0%])
>
> nmethod state distribution
> in-use 1705# 6238 kB (hdr 7%, loc 6%, code 52%,
> stub 4%, [oops 0%, data 0%, pcs 9%])
> not-entrant 29# 191 kB (hdr 4%, loc 5%, code 56%,
> stub 2%, [oops 0%, data 0%, pcs 11%])
> zombie 63# 303 kB (hdr 5%, loc 6%, code 53%,
> stub 4%, [oops 0%, data 0%, pcs 10%])
> unloaded 0#
>
>
> Do you think that is OK, or is that too much information?
>
> @Christian, @Vladimir
> I removed PrintCodeCache2 (+Verbose option) and instead introduced
> -XX:PrintCodeCacheDetails=option where option can be:
> "off: print no additional code cache information"
> "on: print detailed code cache information when exiting"
> "content: print nmethod size distribution and names when
> exiting"
> "oop_map: print oop map usage when exiting"
> "dep_check_time: print nmethod dependency checking
> information when exiting"
> "trace: print code cache actions during execution"
> "all: print all of the above")
>
> PrintCodeCacheDetails is a 'develop' flag.
>
> @Chris P.
> If you think we should add more buffer blob information, I can add
> that. We could use
> -XX:PrintCodeCacheDetails=buffer_blobs, or something similar.
>
>
> Best,
> Albert
>
>
>
> On 27.08.2013 20:37, Vladimir Kozlov wrote:
>> Albert,
>>
>> I like your new output but when is next info is produced?:
>>
>> Java methods = 67K (hdr 0%, loc 3%, code 41%, stub 0%, [oops 0%,
>> data 0%, pcs 40%])
>> Why you changed type to size_t? Please, don't do that. You will not
>> be able to use %d format in 64-bit VM and we may loose atomicity of
>> increment instructions on some platforms. Counters and sizes should
>> fit int since current limit for CodeCache is 2Gb.
>>
>> Leave current flags (except PrintCodeCache2 which even I did know
>> until recently) as they are because there are tests on them already
>> and people know about them.
>>
>> I agree that we can use new PrintCodeCacheDetails flag for details
>> selection. Use Christian suggestion (see NativeMemoryTracking but
>> list all values in globals.hpp flag's description).
>>
>> Thanks,
>> Vladimir
>>
>> On 8/26/13 11:45 PM, Albert Noll wrote:
>>> Hi,
>>>
>>> Chris P., Vladimir, and Christian T., thanks for looking at the code.
>>>
>>> One note: We currently have a lot of -XX flags to provide information
>>> about the code
>>> cache (PrintCodeCache, PrintCodeCacheDetails, +Verbose,
>>> PrintCodecacheOnCompilation,
>>> and PrintCodeCacheAllocation.
>>>
>>> We could combine these flags (or at least some of them) into one
>>> Integer
>>> flag that gives the
>>> level of detail that is printed. For example, we could make
>>> -XX:PrintCodeCache=int
>>> where: (this suggestion is not contained in the current patch)
>>>
>>> int==0 -> no debug output
>>> int==1 -> same debug output is PrintCodeCache
>>> int==2 -> same debug output as PrintCodeCodeCacheDetails
>>> int==3 -> same debug output as with int==1 and int==2 + Verbose
>>> int==4 -> same debug output as with int==3 +
>>> PrintCodeCacheOnCompilation
>>> int==5-> same debug output as with int==4 + PrintCodeCacheAllocation
>>>
>>> Having levels of detail that can be specified via a variable seems
>>> intuitive to
>>> me. Please let me know what you think.
>>>
>>> Here is the new webrev:
>>> http://cr.openjdk.java.net/~anoll/8005885/webrev.01/
>>> <http://cr.openjdk.java.net/%7Eanoll/8005885/webrev.01/>
>>>
>>>
>>> I modified the patch so that the output is less verbose. Here are
>>> samples of
>>> the output:
>>>
>>>
>>> java -XX:+PrintCodeCache ...
>>> CodeCache: size=245760kB used=8862kB max_used=9120kB free=236897kB
>>> Interpreter=799kB live_nmethods=1565(6894kB) dead_nmethods=34(196kB)
>>> stubs=77(1518kB) adapters=212(159kB)
>>> bounds [0x00007f1195000000, 0x00007f1195900000, 0x00007f11a4000000]
>>> compilation: enabled
>>>
>>> java -XX:+PrintCodeCache -XX:+PrintCodeCacheDetails
>>> CodeCache: size=245760kB used=9110kB max_used=9126kB free=236649kB
>>> Interpreter=799kB live_nmethods=1607(7267kB) dead_nmethods=11(71kB)
>>> stubs=77(1515kB) adapters=212(159kB)
>>> bounds [0x00007f81cbb7c000, 0x00007f81cc47c000, 0x00007f81dab7c000]
>>> compilation: enabled
>>>
>>> Code cache entries: (total of #1907)
>>> nmethods: #1618 7338kB
>>> Java: #1576 7295kB
>>> Tier 1: #236 213kB
>>> Tier 2: #792 3280kB
>>> Tier 3: #358 2349kB
>>> Tier 4: #190 1451kB
>>> Native: #42 43kB
>>> runtime-stubs: #59 44kB
>>> adapters: #212 159kB
>>> buffer blobs: #12 1467kB
>>> deopt-stubs: #1 1kB
>>> uncommon-traps: #1 0kB
>>> others: #4 2kB
>>>
>>> nmethod state distribution
>>> in-use: #1562 6596kB
>>> not-entrant: #45 670kB
>>> zombie: #11 71kB
>>> unloaded: #0 0kB
>>>
>>> java -XX:+PrintCodeCache -XX:+PrintCodeCacheDetails -XX:+Verbose
>>> CodeCache: size=245760kB used=8907kB max_used=8995kB free=236852kB
>>> Interpreter=799kB live_nmethods=1584(6973kB) dead_nmethods=29(164kB)
>>> stubs=78(1517kB) adapters=212(159kB)
>>> bounds [0x00007f4c4bda8000, 0x00007f4c4c688000, 0x00007f4c5ada8000]
>>> compilation: enabled
>>>
>>> Code cache entries: (total of #1903)
>>> nmethods: #1613 7137kB
>>> Java: #1572 7095kB
>>> Tier 1: #245 221kB
>>> Tier 2: #792 3261kB
>>> Tier 3: #343 2238kB
>>> Tier 4: #192 1373kB
>>> Native: #41 42kB
>>> runtime-stubs: #59 44kB
>>> adapters: #212 159kB
>>> buffer blobs: #13 1469kB
>>> deopt-stubs: #1 1kB
>>> uncommon-traps: #1 0kB
>>> others: #4 2kB
>>>
>>> nmethod state distribution
>>> in-use: #1537 6447kB
>>> not-entrant: #47 526kB
>>> zombie: #29 164kB
>>> unloaded: #0 0kB
>>>
>>> nmethod size distribution (non-zombie java)
>>> 0 - 512 bytes 556
>>> 512 - 1024 bytes 318
>>> 1024 - 1536 bytes 156
>>> 1536 - 2048 bytes 109
>>> 2048 - 2560 bytes 87
>>> 2560 - 3072 bytes 56
>>> 3072 - 3584 bytes 40
>>> 3584 - 4096 bytes 32
>>> 4096 - 4608 bytes 28
>>> 4608 - 5120 bytes 31
>>> 5120 - 5632 bytes 10
>>> 5632 - 6144 bytes 12
>>> 6144 - 6656 bytes 8
>>> 6656 - 7168 bytes 11
>>> 7168 - 7680 bytes 12
>>> 7680 - 8192 bytes 14
>>> 8192 - 8704 bytes 2
>>> 8704 - 9216 bytes 7
>>> 9216 - 9728 bytes 6
>>> 9728 - 10240 bytes 4
>>> 10240 - 10752 bytes 5
>>> 10752 - 11264 bytes 7
>>> 11264 - 11776 bytes 1
>>> 11776 - 12288 bytes 2
>>> 12288 - 12800 bytes 1
>>> 12800 - 13312 bytes 3
>>> 13312 - 13824 bytes 2
>>> 13824 - 14336 bytes 3
>>> 14336 - 14848 bytes 2
>>> 14848 - 15360 bytes 6
>>> 15360 - 15872 bytes 5
>>> 15872 - 16384 bytes 1
>>> 16896 - 17408 bytes 1
>>> 17408 - 17920 bytes 1
>>> 17920 - 18432 bytes 3
>>> 18432 - 18944 bytes 2
>>> 18944 - 19456 bytes 2
>>> 19968 - 20480 bytes 2
>>> 22016 - 22528 bytes 3
>>> 22528 - 23040 bytes 1
>>> 23552 - 24064 bytes 2
>>> 25088 - 25600 bytes 1
>>> 25600 - 26112 bytes 2
>>> 26112 - 26624 bytes 1
>>> 27136 - 27648 bytes 1
>>> 27648 - 28160 bytes 1
>>> 28672 - 29184 bytes 1
>>> 30208 - 30720 bytes 1
>>> 31744 - 32256 bytes 1
>>> 35328 - 35840 bytes 1
>>> 35840 - 36352 bytes 1
>>> 36864 - 37376 bytes 1
>>> 37376 - 37888 bytes 1
>>> 41472 - 41984 bytes 1
>>> 43520 - 44032 bytes 1
>>> 47104 - 47616 bytes 1
>>> 49664 - 50176 bytes 1
>>> 58368 - 58880 bytes 1
>>> nmethod dependency checking time 0.205156
>>>
>>> java -XX:+PrintCodeCacheOnCompilation
>>> CodeCache: size=245760kB used=1610kB max_used=1610kB free=244149kB
>>>
>>> java -XX:PrintCodeCacheAllocation:
>>> CodeCache allocation: addr: 0x00007f7ed1190850, size: 1984B
>>>
>>> Best,
>>> Albert
>>>
>>> On 23.08.2013 21:24, Christian Thalinger wrote:
>>>> On Aug 23, 2013, at 11:34 AM, Vladimir
>>>> Kozlov<vladimir.kozlov at oracle.com> wrote:
>>>>
>>>>> Albert,
>>>>>
>>>>> I think you are missing constant section from nmethods or
>>>>> something else because % are not add up to 100%. Can you also try
>>>>> on SPARC?
>>>>>
>>>>> #500 Java methods = 1119K (hdr 12%, loc 4%, code 38%, stub 2%,
>>>>> [oops 0%, data 1%, pcs 24%])
>>>>>
>>>>> Use Kb when you show size.
>>>> Actually, kB (http://en.wikipedia.org/wiki/Kilobyte).
>>>>
>>>>> I agree with Chris P. that output is too verbose for product *by
>>>>> default* - I thinks we don't need splitting per tiers and detail
>>>>> section sizes information. Note, this will be put into hs_err
>>>>> files. I don't see how this additional information will help to
>>>>> debug problems.
>>>>>
>>>>> I think by default PrintCodeCache should should sligthly verbose
>>>>> current output: add sizes, split live/dead nmethods, add
>>>>> interpreter and stubs instead of blobs and may be something else:
>>>>>
>>>>> CodeCache: size=49152Kb used=1729Kb max_used=1782Kb free=47422Kb
>>>>> bounds [0x00007fbc13fb1000, 0x00007fbc14221000, 0x00007fbc16fb1000]
>>>>> interpreter=199Kb stubs=302(400Kb) live_nmethods=510(1119Kb)
>>>>> dead_nmethods=2(85Kb) adapters=254(116Kb)
>>>>> compilation: enabled
>>>>>
>>>>>
>>>>> It could be important when you are working on codecache
>>>>> improvement or want to see how it is used. And, yes it would be
>>>>> nice to get detailed info in product VM also. Unfortunately
>>>>> Verbose flag is not product and in some places it guards code
>>>>> which we don't want in product VM so we can't make it product.
>>>>>
>>>>> Maybe you can convert PrintCodeCache2 to 'diagnostic' flag and use
>>>>> it for detailed information (it already does additional printing).
>>>>> But add new develop flag to replace it in print_trace():
>>>>>
>>>>> void CodeCache::print_trace(const char* event, CodeBlob* cb, int
>>>>> size) {
>>>>> if (PrintCodeCache2) { // Need to add a new flag
>>>> I agree with Vladimir. Can you also rename PrintCodeCache2 to
>>>> PrintCodeCacheDetails?
>>>>
>>>> -- Chris
>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 8/23/13 6:31 AM, Albert Noll wrote:
>>>>>> Hi,
>>>>>>
>>>>>> could I get reviews for the following patch?
>>>>>>
>>>>>> jbs:https://bugs.openjdk.java.net/browse/JDK-8005885
>>>>>> webrev:http://cr.openjdk.java.net/~anoll/8005885/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Eanoll/8005885/webrev.00/>
>>>>>>
>>>>>> Many thanks in advance,
>>>>>> Albert
>>>>>>
>>>>>> Problem: Currently we only print:
>>>>>>
>>>>>> CodeCache:
>>>>>> nmethod dependency checking time 0.037552
>>>>>> #944 live = 3681K (hdr 4%, loc 2%, code 74%, stub 1%, [oops 0%,
>>>>>> data
>>>>>> 0%, pcs 5%])
>>>>>> #92 dead = 247K (hdr 7%, loc 6%, code 46%, stub 3%, [oops 0%,
>>>>>> data 0%,
>>>>>> pcs 12%])
>>>>>>
>>>>>> It would be helpful to have more detailed information about the
>>>>>> code cache.
>>>>>>
>>>>>> Solution: add more detailed information about the content of the
>>>>>> code
>>>>>> cache when
>>>>>> exiting the VM.
>>>>>>
>>>>>>
>>>>>> See sample outputs:
>>>>>> java -XX:-TieredCompilation -XX:+PrintCodeCache -jar
>>>>>> dacapo-9.12-bach.jar fop
>>>>>> ===== DaCapo 9.12 fop starting =====
>>>>>> ===== DaCapo 9.12 fop PASSED in 7676 msec =====
>>>>>> CodeCache: size=49152Kb used=1729Kb max_used=1782Kb free=47422Kb
>>>>>> bounds [0x00007fbc13fb1000, 0x00007fbc14221000,
>>>>>> 0x00007fbc16fb1000]
>>>>>> total_blobs=814 nmethods=512 adapters=254
>>>>>> compilation: enabled
>>>>>>
>>>>>> Interpreter: total=199k, used=124k
>>>>>>
>>>>>> Total number of live methods: 510
>>>>>> Tier 1:
>>>>>> #0 Java methods
>>>>>> #0 OSR methods
>>>>>> Tier 2:
>>>>>> #0 Java methods
>>>>>> #0 OSR methods
>>>>>> Tier 3:
>>>>>> #0 Java methods
>>>>>> #0 OSR methods
>>>>>> Tier 4:
>>>>>> #500 Java methods = 1119K (hdr 12%, loc 4%, code 38%, stub
>>>>>> 2%, [oops
>>>>>> 0%, data 1%, pcs 24%])
>>>>>> #5 OSR methods = 37K (hdr 3%, loc 3%, code 41%, stub 2%,
>>>>>> [oops 0%,
>>>>>> data 1%, pcs 30%])
>>>>>> Native methods:
>>>>>> #5 Native methods = 4K (hdr 31%, loc 10%, code 55%, stub 0%,
>>>>>> [oops
>>>>>> 0%, data 0%, pcs 0%])
>>>>>>
>>>>>> Total number of dead methods: 2
>>>>>> Tier 1:
>>>>>> #0 Java methods
>>>>>> #0 OSR methods
>>>>>> Tier 2:
>>>>>> #0 Java methods
>>>>>> #0 OSR methods
>>>>>> Tier 3:
>>>>>> #0 Java methods
>>>>>> #0 OSR methods
>>>>>> Tier 4:
>>>>>> #1 Java methods = 67K (hdr 0%, loc 3%, code 41%, stub 0%,
>>>>>> [oops 0%,
>>>>>> data 0%, pcs 40%])
>>>>>> #1 OSR methods = 18K (hdr 1%, loc 4%, code 39%, stub 2%,
>>>>>> [oops 0%,
>>>>>> data 1%, pcs 31%])
>>>>>> Native methods:
>>>>>> #0 Native methods
>>>>>>
>>>>>> Total number of stubs: 302
>>>>>> #23 runtime = 5K (hdr 25%, loc 1%, code 67%, stub 0%, [oops
>>>>>> 0%, data
>>>>>> 0%, pcs 0%])
>>>>>> #1 deoptimization = 1K (hdr 7%, loc 0%, code 89%, stub 0%,
>>>>>> [oops 0%,
>>>>>> data 0%, pcs 0%])
>>>>>> #1 uncommon trap = 0K (hdr 13%, loc 1%, code 83%, stub 0%,
>>>>>> [oops 0%,
>>>>>> data 0%, pcs 0%])
>>>>>> #1 exception = 0K (hdr 27%, loc 3%, code 65%, stub 0%, [oops 0%,
>>>>>> data 0%, pcs 0%])
>>>>>> #3 safepoint = 1K (hdr 10%, loc 1%, code 86%, stub 0%, [oops 0%,
>>>>>> data 0%, pcs 0%])
>>>>>> #254 C2I/I2C adapter = 116K (hdr 13%, loc 1%, code 82%, stub 0%,
>>>>>> [oops 0%, data 0%, pcs 0%])
>>>>>> #0 method handles adapter
>>>>>> #19 other = 308K (hdr 0%, loc 0%, code 99%, stub 0%, [oops
>>>>>> 0%, data
>>>>>> 0%, pcs 0%])
>>>>>>
>>>>>>
>>>>>> java -XX:+TieredCompilation -XX:+PrintCodeCache -jar
>>>>>> dacapo-9.12-bach.jar fop
>>>>>> ===== DaCapo 9.12 fop starting =====
>>>>>> ===== DaCapo 9.12 fop PASSED in 4850 msec =====
>>>>>> CodeCache: size=245760Kb used=7355Kb max_used=7370Kb free=238404Kb
>>>>>> bounds [0x00007f49fd000000, 0x00007f49fd740000,
>>>>>> 0x00007f4a0c000000]
>>>>>> total_blobs=2578 nmethods=2240 adapters=254
>>>>>> compilation: enabled
>>>>>>
>>>>>> Interpreter: total=199k, used=123k
>>>>>>
>>>>>> Total number of live methods: 2205
>>>>>> Tier 1:
>>>>>> #466 Java methods = 333K (hdr 39%, loc 5%, code 25%, stub
>>>>>> 19%, [oops
>>>>>> 0%, data 0%, pcs 1%])
>>>>>> #0 OSR methods
>>>>>> Tier 2:
>>>>>> #429 Java methods = 1047K (hdr 11%, loc 5%, code 40%, stub
>>>>>> 8%, [oops
>>>>>> 0%, data 1%, pcs 18%])
>>>>>> #0 OSR methods
>>>>>> Tier 3:
>>>>>> #1069 Java methods = 3817K (hdr 7%, loc 4%, code 53%, stub
>>>>>> 5%, [oops
>>>>>> 0%, data 0%, pcs 17%])
>>>>>> #5 OSR methods = 92K (hdr 1%, loc 4%, code 57%, stub 2%,
>>>>>> [oops 0%,
>>>>>> data 0%, pcs 23%])
>>>>>> Tier 4:
>>>>>> #190 Java methods = 648K (hdr 8%, loc 3%, code 43%, stub 1%,
>>>>>> [oops
>>>>>> 0%, data 1%, pcs 26%])
>>>>>> #3 OSR methods = 15K (hdr 5%, loc 3%, code 47%, stub 1%,
>>>>>> [oops 0%,
>>>>>> data 0%, pcs 28%])
>>>>>> Native methods:
>>>>>> #43 Native methods = 37K (hdr 31%, loc 10%, code 55%, stub
>>>>>> 0%, [oops
>>>>>> 0%, data 0%, pcs 0%])
>>>>>>
>>>>>> Total number of dead methods: 35
>>>>>> Tier 1:
>>>>>> #0 Java methods
>>>>>> #0 OSR methods
>>>>>> Tier 2:
>>>>>> #3 Java methods = 22K (hdr 3%, loc 5%, code 40%, stub 6%,
>>>>>> [oops 0%,
>>>>>> data 1%, pcs 27%])
>>>>>> #0 OSR methods
>>>>>> Tier 3:
>>>>>> #31 Java methods = 193K (hdr 4%, loc 4%, code 54%, stub 3%,
>>>>>> [oops
>>>>>> 0%, data 0%, pcs 21%])
>>>>>> #1 OSR methods = 2K (hdr 11%, loc 5%, code 52%, stub 7%,
>>>>>> [oops 0%,
>>>>>> data 0%, pcs 7%])
>>>>>> Tier 4:
>>>>>> #0 Java methods
>>>>>> #0 OSR methods
>>>>>> Native methods:
>>>>>> #0 Native methods
>>>>>>
>>>>>> Total number of stubs: 338
>>>>>> #57 runtime = 24K (hdr 14%, loc 3%, code 79%, stub 0%, [oops 0%,
>>>>>> data 0%, pcs 0%])
>>>>>> #1 deoptimization = 1K (hdr 7%, loc 0%, code 89%, stub 0%,
>>>>>> [oops 0%,
>>>>>> data 0%, pcs 0%])
>>>>>> #1 uncommon trap = 0K (hdr 13%, loc 1%, code 83%, stub 0%,
>>>>>> [oops 0%,
>>>>>> data 0%, pcs 0%])
>>>>>> #1 exception = 0K (hdr 27%, loc 3%, code 65%, stub 0%, [oops 0%,
>>>>>> data 0%, pcs 0%])
>>>>>> #3 safepoint = 1K (hdr 10%, loc 1%, code 86%, stub 0%, [oops 0%,
>>>>>> data 0%, pcs 0%])
>>>>>> #254 C2I/I2C adapter = 116K (hdr 13%, loc 1%, code 82%, stub 0%,
>>>>>> [oops 0%, data 0%, pcs 0%])
>>>>>> #0 method handles adapter
>>>>>> #21 other = 871K (hdr 0%, loc 0%, code 99%, stub 0%, [oops
>>>>>> 0%, data
>>>>>> 0%, pcs 0%])
>>>>>>
>>>>>>
>>>>>> Please let me know if you think more/less/different data should
>>>>>> be printed.
>>>
>
>
>
More information about the hotspot-compiler-dev
mailing list