linux os processor optimizations for OpenJDK GC performance enhancement

[David Holmes]

Hi Ramki,

On 19/04/2017 8:27 AM, Ram Krishnan wrote:
> Hi David,
>
> Thanks for the clarification.
>
> I have signed the OCA and mailed it to oracle-ca_us(at)oracle.com
> <http://oracle.com>. Any help to expedite processing would be much
> appreciated.

Can't help with that I'm afraid. :)

> We are seeing promising POC results (details in the google doc) for this
> proposal -- would really appreciate your help in moving this forward.

If you email me a text/html version of the document I can host it on 
cr.openjdk.java.net temporarily. For this to become a JEP you will need 
a sponsor with the necessary OpenJDK credentials.

http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

Cheers,
David


> Thanks,
> Ramki
>
> On Tue, Apr 18, 2017 at 1:55 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Ramki,
>
>     On 19/04/2017 12:34 AM, Ram Krishnan wrote:
>
>         Please find detailed proposal below, looking forward to your
>         comments.
>
>         "Minimize application tail latency using
>         cache-partitioning-aware G1GC" --
>         https://docs.google.com/document/d/1rPMG4XUiE7cUEOogW1z5tBbBZTclOWyg0arhuycXN94/edit
>         <https://docs.google.com/document/d/1rPMG4XUiE7cUEOogW1z5tBbBZTclOWyg0arhuycXN94/edit>
>
>
>     All contributions to OpenJDK need to be hosted on OpenJDK
>     infrastructure not on external systems like the above.
>
>     Also I can not see you listed as an OCA signatory. Are you an
>     OpenJDK contributor?
>
>     Thanks,
>     David
>     -----
>
>         Thanks,
>         Ramki
>
>         On Thu, Apr 13, 2017 at 11:04 PM, Bernd Eckenfels
>         <ecki at zusammenkunft.net <mailto:ecki at zusammenkunft.net>>
>         wrote:
>
>             Maybe it would be better to concentrate the processor
>             optimizations on
>             accessors and barrriers without introducing a completely new GC
>             architecture. I can imagine that especially in the area of
>             NUMA, TLAB, huge
>             pages, cache consistency and possibly MMX extensions there
>             is some
>             potential.
>
>             Abandoning the global STW - while it seems like a pretty
>             powerful change -
>             is I guess not a good starter exercise. Especially since it
>             is not only a
>             question of mutator threads.
>
>             Gruss
>             Bernd
>             --
>             http://bernd.eckenfels.net
>             ------------------------------
>             *From:* hotspot-gc-dev
>             <hotspot-gc-dev-bounces at openjdk.java.net
>             <mailto:hotspot-gc-dev-bounces at openjdk.java.net>> on
>             behalf of Ram Krishnan <ramkri123 at gmail.com
>             <mailto:ramkri123 at gmail.com>>
>             *Sent:* Friday, April 14, 2017 6:36:27 AM
>             *To:* Asif Qamar; Andrew Haley;
>             hotspot-gc-dev at openjdk.java.net
>             <mailto:hotspot-gc-dev at openjdk.java.net>
>             *Subject:* Re: linux os processor optimizations for OpenJDK GC
>             performance enhancement
>
>             Thanks Andrew.
>
>             ​>>Surely there is: a thread could have its TLAB allocated
>             from a region
>
>                     local to that socket (or core), and the GC thread
>                     for that region
>                     could run on the same socket.  It only works for
>                     young gen, but that's
>                     a lot of the problem.
>
>
>             A clarification -- does the TLAB allocation apply to tenured
>             space also?
>             If not, the above would work only for young gen cases where
>             there is no
>             promotion to tenured right?
>
>             Thanks,
>             Ramki
>
>             On Thu, Apr 13, 2017 at 12:55 PM, Ram Krishnan
>             <ramkri123 at gmail.com <mailto:ramkri123 at gmail.com>>
>             wrote:
>
>
>                 ---------- Forwarded message ----------
>                 From:
>                 ​​
>                 Andrew Haley <aph at redhat.com <mailto:aph at redhat.com>>
>                 Date: Thu, Apr 13, 2017 at 9:52 AM
>                 Subject: Re: linux os processor optimizations for
>                 OpenJDK GC performance
>                 enhancement
>                 To:
>                 ​​
>                 hotspot-gc-dev at openjdk.java.net
>                 <mailto:hotspot-gc-dev at openjdk.java.net>
>
>
>                 On 13/04/17 16:33, Kim Barrett wrote:
>
>                     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.
>
>
>                 ​​
>                 Surely there is: a thread could have its TLAB allocated
>                 from a region
>                 local to that socket (or core), and the GC thread for
>                 that region
>                 could run on the same socket.  It only works for young
>                 gen, but that's
>                 a lot of the problem.
>
>                 Andrew.
>
>
>
>
>                 --
>                 Thanks,
>                 Ramki
>
>
>
>
>             --
>             Thanks,
>             Ramki
>
>
>
>
>
>
>
> --
> Thanks,
> Ramki