RFR 8166929: [JVMCI] Expose decompile counts in MDO

[Christian Thalinger]

> On Sep 30, 2016, at 1:04 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
> 
>> 
>> On Sep 30, 2016, at 3:32 PM, Christian Thalinger <cthalinger at twitter.com <mailto:cthalinger at twitter.com>> wrote:
>> 
>> 
>>> On Sep 30, 2016, at 6:07 AM, Tom Rodriguez <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>> wrote:
>>> 
>>> 
>>>> On Sep 29, 2016, at 7:16 PM, Vitaly Davidovich <vitalyd at gmail.com <mailto:vitalyd at gmail.com>> wrote:
>>>> 
>>>> Quick fly-by comment: HotSpotMethodData::toString should use %d for overflow recompiles count printing, like the other counters.
>>> 
>>> Thanks, that was a typo.  Fixed and updated in place.
>> 
>> +  COMPILER2_OR_JVMCI_PRESENT(nonstatic_field(MethodCounters, _interpreter_invocation_count,   int))                                  \
>> +  COMPILER2_OR_JVMCI_PRESENT(nonstatic_field(MethodCounters, _interpreter_throwout_count,     u2))                                   \
>> Isn’t that true always?
> 
> Yes, it is here.  I copied those lines from the normal vmstructs database where it might not be true but they can be removed here.  While fixing this I also realized that InvocationCounter wasn’t declared in the JVMCI copy of vmstructs, so I added that.
> 
>> 
>> +    public int getDecompileCount() {
>> +        return UNSAFE.getInt(metaspaceMethodData + config.methodDataDecompiles);
>> +    }
>> +
>> +    public int getOverflowRecompileCount() {
>> +        return UNSAFE.getInt(metaspaceMethodData + config.methodDataOverflowRecompiles);
>> +    }
>> +
>> +    public int getOverflowTrapsCount() {
>> +        return UNSAFE.getInt(metaspaceMethodData + config.methodDataOverflowTraps);
>> +    }
>> This is high-level nitpicking:  the fields are plural but you named the methods singular except “OverflowTraps”.  Either plural everywhere or none.
> 
> Yes I fixed that in 8 while preparing this webrev but I missed updating in it 9.  I’ve put the updated webrev at http://cr.openjdk.java.net/~never/8166929.1/webrev <http://cr.openjdk.java.net/~never/8166929.1/webrev>
Looks good.

Unrelated question:
         String nl = String.format("%n");
         String nlIndent = String.format("%n%38s", "");
+        sb.append("Raw method data for ");
+        sb.append(method.format("%H.%n(%p)"));
+        sb.append(":");
+        sb.append(nl);
+        sb.append(String.format("nof_decompiles(%d) nof_overflow_recompiles(%d) nof_overflow_traps(%d)%n",
+                        getDecompileCount(), getOverflowRecompileCount(), getOverflowTrapCount()));
Is pre-formatting nl really a win?  If yes, why are we not doing the same trick on the last line?

> 
> tom
> 
>> 
>>> 
>>> tom
>>> 
>>>> 
>>>> Thanks
>>>> 
>>>> On Thursday, September 29, 2016, Tom Rodriguez <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>> wrote:
>>>> http://cr.openjdk.java.net/~never/8166929/webrev <http://cr.openjdk.java.net/~never/8166929/webrev>
>>>> https://bugs.openjdk.java.net/browse/JDK-8166929 <https://bugs.openjdk.java.net/browse/JDK-8166929>
>>>> 
>>>> This is a minor API addition to expose some of the top-level MDO decompile and recompile counts.  It’s necessary to detect recompilation pathologies.  Tested by printing MDOs from JVMCI.  I also fixed a few problems I discovered with the formatting of the MDO printed form.
>>>> 
>>>> tom
>>>> 
>>>> 
>>>> -- 
>>>> Sent from my phone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160930/7eaf19a9/attachment-0001.html>