[PATCH] Exploit Empty Regions in Young Gen to Enhance PS Full GC Performance

Stefan Johansson stefan.johansson at oracle.com
Thu Oct 10 12:37:18 UTC 2019


Hi,

On 2019-10-10 13:06, Haoyu Li wrote:
> Hi Stefan,
> 
> Thanks for your testing! One possible reason for the regressions in 
> simple tests is that the region dependencies maybe not heavy enough. 
> Because the locality of shadow regions is lower than that of heap 
> regions, writing to shadow regions will be slower than to normal 
> regions, and this is a part of the reason why I reuse shadow regions. 
> Therefore, if only a few shadow regions are created and not reused, the 
> overhead may not be amortized.

I guess it is something like this. I thought that for "easy" heaps the 
shadow regions won't be used at all, and should therefor not really cost 
anything.

> 
> As to the OCA, it is the case that I'm the only person signing the 
> agreement. Please let me know if you have any further questions. Thanks 
> again!

Ok, so you are the sole author of the patch. The important part, as the 
agreement states, is:
"no other person or entity, including my employer, has or will have 
rights with respect my contributions"

Is that the case?

Thanks,
Stefan

> 
> Best Regrads,
> Haoyu Li
> 
> Stefan Johansson <stefan.johansson at oracle.com 
> <mailto:stefan.johansson at oracle.com>> 于2019年10月8日周二 下午6:49写道:
> 
>     Hi Haoyu,
> 
>     I've done some more testing and I haven't seen any issues with the
>     patch
>     so far and the performance looks promising in most cases. For simple
>     tests I've seen some regressions, but I'm not really sure why. Will do
>     some more digging.
> 
>     To move forward with this the first thing we need to do is making sure
>     that you being covered by the Oracle Contributor Agreement is enough.
>       From what we can see it is only you as an individual that has signed
>     the OCA and in that case it is important that this statement from the
>     OCA is fulfilled: "no other person or entity, including my employer,
>     has
>     or will have rights with respect my contributions"
> 
>     Is this the case for this contribution or should we have the university
>     sign the OCA as well? For more information regarding the OCA please
>     refer to:
>     https://www.oracle.com/technetwork/oca-faq-405384.pdf
> 
>     Thanks,
>     Stefan
> 
>     On 2019-09-16 16:02, Haoyu Li wrote:
>      > FYI, the evaluation results on OpenJDK 14 are plotted in the
>     attachment.
>      > I compute the full GC throughput by dividing the heap size before
>     full
>      > GC by the GC pause time, and the results are arithmetic mean
>     values of
>      > ten runs after a warm-up run. The evaluation is conducted on a
>     machine
>      > with dual Intel ®XeonTM E5-2618L v3 CPUs (2 sockets, 16 physical
>     cores
>      > with SMT enabled) and 64G DRAM.
>      >
>      > Best Regrads,
>      > Haoyu Li,
>      > Institute of Parallel and Distributed Systems(IPADS),
>      > School of Software,
>      > Shanghai Jiao Tong University
>      >
>      >
>      > Stefan Johansson <stefan.johansson at oracle.com
>     <mailto:stefan.johansson at oracle.com>
>      > <mailto:stefan.johansson at oracle.com
>     <mailto:stefan.johansson at oracle.com>>> 于2019年9月12日周四 上午5:34
>     写道:
>      >
>      >     Hi Haoyu,
>      >
>      >     I recently came across your patch and I would like to pick up on
>      >     some of the things Kim mentioned in his mails. I especially want
>      >     evaluate and investigate if this is a technique we can use to
>      >     improve the other GCs as well. To start that work I want to
>     take the
>      >     patch for a spin in our internal performance testing. The patch
>      >     doesn’t apply clean to the latest JDK repository, so if you could
>      >     provide an updated patch that would be very helpful.
>      >
>      >     It would also be great if you could share some more information
>      >     around the results presented in the paper. For example, it
>     would be
>      >     good to get the full command lines for the different
>     benchmarks so
>      >     we can run them locally and reproduce the results you’ve seen.
>      >
>      >     Thanks,
>      >     Stefan
>      >
>      >>     12 mars 2019 kl. 03:21 skrev Haoyu Li <leihouyju at gmail.com
>     <mailto:leihouyju at gmail.com>
>      >>     <mailto:leihouyju at gmail.com <mailto:leihouyju at gmail.com>>>:
>      >>
>      >>     Hi Kim,
>      >>
>      >>     Thanks for reviewing and testing the patch. If there are any
>      >>     failures or performance degradation relevant to the work, please
>      >>     let me know and I'll be very happy to keep improving it.
>     Also, any
>      >>     suggestions about code improvements are well appreciated.
>      >>
>      >>     I'm not quite sure if both G1 and Shenandoah have the similar
>      >>     region dependency issue, since I haven't studied their GC
>      >>     behaviors before. If they have, I'm also willing to propose
>     a more
>      >>     general optimization.
>      >>
>      >>     As to the memory overhead, I believe it will be low because this
>      >>     patch exploits empty regions in the young space rather than
>      >>     off-heap memory to allocate shadow regions, and also reuses the
>      >>     /_source_region/ field of each /RegionData /to record the
>      >>     correspongding shadow region index. We only introduce a new
>      >>     integer filed /_shadow /in the RegionData class to indicate the
>      >>     status of a region, a global /GrowableArray _free_shadow/ to
>     store
>      >>     the indices of shadow regions, and a global /Monitor/ to protect
>      >>     the array. These information might help if the memory overhead
>      >>     need to be evaluated.
>      >>
>      >>     Looking forward to your insight.
>      >>
>      >>     Best Regrads,
>      >>     Haoyu Li,
>      >>     Institute of Parallel and Distributed Systems(IPADS),
>      >>     School of Software,
>      >>     Shanghai Jiao Tong University
>      >>
>      >>
>      >>     Kim Barrett <kim.barrett at oracle.com
>     <mailto:kim.barrett at oracle.com>
>      >>     <mailto:kim.barrett at oracle.com
>     <mailto:kim.barrett at oracle.com>>> 于2019年3月12日周二 上午6:11写道:
>      >>
>      >>         > On Mar 11, 2019, at 1:45 AM, Kim Barrett
>      >>         <kim.barrett at oracle.com <mailto:kim.barrett at oracle.com>
>     <mailto:kim.barrett at oracle.com <mailto:kim.barrett at oracle.com>>> wrote:
>      >>         >
>      >>         >> On Jan 24, 2019, at 3:58 AM, Haoyu Li
>     <leihouyju at gmail.com <mailto:leihouyju at gmail.com>
>      >>         <mailto:leihouyju at gmail.com
>     <mailto:leihouyju at gmail.com>>> wrote:
>      >>         >>
>      >>         >> Hi Kim,
>      >>         >>
>      >>         >> I have ported my patch to OpenJDK 13 according to your
>      >>         instructions in your last mail, and the patch is attached in
>      >>         this mail. The patch does not change much since PSGC is
>     indeed
>      >>         pretty stable.
>      >>         >>
>      >>         >> Also, I evaluate the correctness and performance of
>     PS full
>      >>         GC with benchmarks from DaCapo, SPECjvm2008, and JOlden
>     suits
>      >>         on a machine with dual Intel Xeon E5-2618L v3 CPUs(16
>     physical
>      >>         cores), 64G DRAM and linux kernel 4.17. The evaluation
>     result,
>      >>         indicating 1.9X GC throughput improvement on average, is
>      >>         attached, too.
>      >>         >>
>      >>         >> However, I have no idea how to further test this
>     patch for
>      >>         both correctness and performance. Can I please get any
>      >>         guidance from you or some sponsor?
>      >>         >
>      >>         > Sorry I missed that you had sent an updated version of the
>      >>         patch.
>      >>         >
>      >>         > I’ve run the full regression suite across Oracle-supported
>      >>         platforms.  There are some
>      >>         > failures, but there are almost always some failures in the
>      >>         later tiers right now.  I’ll start
>      >>         > looking at them tomorrow to figure out whether any of them
>      >>         are relevant.
>      >>         >
>      >>         > I’m also planning to run some of our performance
>     benchmarks.
>      >>         >
>      >>         > I’ve lightly skimmed the proposed changes.  There might be
>      >>         some code improvements
>      >>         > to be made.
>      >>         >
>      >>         > I’m also wondering if this technique applies to other
>      >>         collectors.  It seems like both G1 and
>      >>         > Shenandoah full gc’s might have similar issues?  If so, a
>      >>         solution that is ParallelGC-specific
>      >>         > is less interesting than one that has broader
>      >>         applicability.  Though maybe this optimization
>      >>         > is less important for G1 and Shenandoah, since they
>     actively
>      >>         try to avoid full gc’s.
>      >>         >
>      >>         > I’m also not clear on how much additional memory might be
>      >>         temporarily allocated by this
>      >>         > mechanism.
>      >>
>      >>         I’ve created a CR for this:
>      >> https://bugs.openjdk.java.net/browse/JDK-8220465
>      >>
>      >
> 



More information about the hotspot-gc-dev mailing list