Questions around codeheaps, codeblobs and code locality
keita abdoul-kader
abdoulk.keita at gmail.com
Fri Jun 7 16:20:48 UTC 2019
On Fri, Jun 7, 2019 at 9:20 AM keita abdoul-kader <abdoulk.keita at gmail.com>
wrote:
> Thanks Tobias for taking the time.
>
> Those are nice improvements indeed. Do you expect the remaining work item
> to (cumulatively) bring comparable gain ? Or have we reach the point of
> diminishing returns?
> Would you mind expanding on how you obtained the heat map on slide 13 and
> 19 of your presentation ? I would like to reproduce those on our internal
> workloads.
>
>
>
>
>
> On Fri, Jun 7, 2019 at 2:51 AM Tobias Hartmann <tobias.hartmann at oracle.com>
> wrote:
>
>> Hi,
>>
>> > On 6/3/19 12:14 PM, keita abdoul-kader wrote:
>> >> I have been looking into the code cache layout and ways to reduce the
>> high
>> >> amount of iTLB we are observing on some of our workloads. It seems that
>> >> after the works on segmented codeHeaps, the plan was to add support
>> for non
>> >> contiguous codeBlobs as the next step to improve code locality in the
>> code
>> >> cache. is the work on non contiguous codeBlobs still active ?
>>
>> With the segmented code cache, we've seen some nice improvements (slide
>> 19 onwards):
>>
>> http://cr.openjdk.java.net/~thartmann/talks/2014-Efficient_Code_Cache_Management.pdf
>>
>> We had several ideas on how to improve things further (see slide 31) but
>> there are currently no
>> plans to work on any of these.
>>
>> >> Also, does the hotspot has support for any form of code compaction ?
>> >> Compacting the code heap is mentioned in one of the comment in
>> >> relocInfo.hpp, but browsing the source code it seems that once the
>> >> codeBlobs is filled with the content of a codeBuffer, they are never
>> moved
>> >> in a way to reduce codeheap fragmentation.
>>
>> No, code in the code cache is not moved/compacted but only removed.
>>
>> >> In general, is there an umbrella project or a set of open task around
>> >> improving code locality ? Please note that most of my observation
>> driving
>> >> this come from spark-sql workloads. Since spark-sql generates
>> dynamically
>> >> generate a lots of code, i might simply be observing a pathological
>> case.
>>
>> No, we don't have any umbrella project for this.
>>
>> Best regards,
>> Tobias
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190607/ca29d856/attachment.html>
More information about the hotspot-compiler-dev
mailing list