[9] RFR(S): 8059606: Enable per-method usage of CompileThresholdScaling (per-method compilation thresholds)

[John Rose]

On Jan 5, 2015, at 11:13 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> On 1/5/15 10:38 AM, Zoltán Majó wrote:
>> ...
>> 
>> Per-method compilation thresholds are available only in non-product builds to avoid the overhead of accessing fields
>> added by the patch MethodData and MethodCounters.
> 
> Too many ifdefs :)
> The interpreter speed is not important. And the feature could be interesting in product VM too.
> The only drawback is 2 additional fields in MDO which is fine.
> Can you make it product and run through our performance infrastructure.
> Also, as John Rose will say, we should have as much as possible a similar code in product as in tested debug code. Otherwise we are not testing product bits and will get into troubles.

Vladimir is right; please consider it said by both of us.  :-)

Zoltan, I am glad you are tackling the profiling code, because we need experts in it.

In the long run, the invocation counter code started complex and is growing more complex.  We need to rationalize the counters more.  The notification frequency idea is a good step in the right direction, since it pulls logic out of the assembly code and into high-level event handling code.  Another good step would be to reduce the number of distinct counters visible at the assembly level, thus simplifying the assembly code.  The complexity of InvocationCounter is a fossil which deserves to be buried and paved over.

Speaking of ifdefs, I am uncomfortable with the ifdef-TIERED branches in the assembly code.  Can we move towards merging those code branches?

And, speaking of footprint, I see no reason why we couldn't shrink the Method layout to handle all counter bookkeeping with a single word, instead of the current two.  Also (while I'm on the subject) low-count, non-looping methods do not need a full MethodCounter struct, just a simple inline count with a low-tag bit, with CAS-based state changes.  This would have the effect of delaying MC and MD allocation  until a method has been used non-trivial amount, which would reduce footprint if "non-trivial amount" turns out to be large.

   counters = union {
     uintptr_t simple_count;  // c = (invocation_count << 16 | notify_mask << 8 | other_flags_we_might_like << 1 | 1)
     uintptr_t method_counters;  // c = ((intptr_t)method_counters_addr | 0)
     uintptr_t method_data;  // c = ((intptr_t)method_data_addr | 0)
   }

(Assumes that method_data and method_counters can be distinguished suitably by their contents.)

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150105/88a757fe/attachment-0001.html>