linux os processor optimizations for OpenJDK GC performance enhancement

[Ram Krishnan]

Thanks Kim for the detailed explanation.

Another possible solution to such a scenario would be to use multiple JVMs,
for example one JVM could be hosting latency sensitive applications and
another JVM could be hosting normal applications. Cache partitioning can be
applied at a JVM level. This way, GC activity (especially data copies) on
the normal JVM will minimally impact the latency sensitive JVM. My thought
process is to focus our initial contribution on this scenario.

Thanks,
Ramki

On Thu, Apr 13, 2017 at 8:33 AM, Kim Barrett <kim.barrett at oracle.com> wrote:

> > On Apr 12, 2017, at 9:27 PM, Ram Krishnan <ramkri123 at gmail.com> wrote:
> >
> > We are working on linux os processor specific optimizations centered
> around cache partitioning and better processor core thread(s) affinity for
> OpenJDK GC performance enhancement with the following benefits
> > - throughput increase
> > - minimizing tail latency for latency sensitive applications
> > - superior isolation in a multi-tenant environment
> >
> > ​We have been looking at the G1GC code/documentation and performed some
> initial experiments. Based on this, what we understand is that STW events
> pause all application threads independent of which regions are being
> impacted by garbage collection. For example, if application thread "x" uses
> regions 1, 4, 5 and  garbage collection is working on regions 2 and 11,
> application thread "x" is paused during the STW event.
> >
> > Your expert opinion on this topic is much appreciated.
> >
> > --
> > ​Thanks in advance,
> > Ramki​
>
> An application thread may touch memory in any region; there is no
> notion of a thread being "scoped" to a specific set of regions. While
> it might happen that a thread would only touch regions not being
> worked on by the collector, there is no a priori way to know that.
>
> If there were some way to allow collector access to a region while
> blocking non-collector access, then it might be possible to defer
> stopping application threads until they do a blocked access. But it's
> not obvious such a scheme would actually be useful, as application
> threads are likely to access young generation regions a lot, and those
> regions are usually of interest during collector pauses.
>
>


-- 
Thanks,
Ramki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170413/b8ac068c/attachment.htm>