RFR (trivial): 8216285: Enable inlining of CollectedHeap::obj-/array-/class_allocate

Roman Kennke rkennke at redhat.com
Tue Jan 8 11:56:13 UTC 2019

>>>>>> Those methods are virtual. How useful is it to flag them 'inline' ?
>>>>> Useful enough to measurably save a few ns/op on Array.newInstance and
>>>>> Object.clone microbenchmarks (when running TieredStopAtLevel=1 to stay
>>>>> in the JNI slow path).
>>>> If a method is virtual, it cannot be inlined, right? Unless you call it
>>>> in a funny non-virtual way. Or what am I missing?
>>> Could be these are the only implementations when compiling without
>>> shenandoah so gcc realizes the virtual can be ignored?
>> I doubt that gcc can make that call. The linker probably could, but at
>> this point it would be too late. C++ is not Java. I don't think the
>> patch hurts, but I doubt its usefulness ;-)
> I only go by what I see in microbenchmarks, and somehow this netted a
> small improvement.


I'm just curious. ;-) Can you by any chance send me the microbenchmark?
Maybe I can figure out what's going on. I suppose there is a chance that
if you call one of those methods with an object of known type, e.g.
G1CollectedHeap*, and the compiler can prove that it cannot be a
subtype, then yeah, it might actually inline it. If the benchmark is
using jmh, you can run with and without the patch with perfasm profiler
and it should show you what's different in the hot path.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20190108/8ceeabe7/signature.asc>

More information about the hotspot-gc-dev mailing list