[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-gc-dev
Subject:    Re: RFC: Epsilon GC JEP
From:       Thomas Schatzl <thomas.schatzl () oracle ! com>
Date:       2017-12-18 9:43:22
Message-ID: 1513590202.2324.27.camel () oracle ! com
[Download RAW message or body]

On Fri, 2017-12-15 at 12:01 -0500, Micha Berger wrote:
> On Fri, Dec 15, 2017 at 09:29:52AM +0100, Thomas Schatzl wrote:
> : I strongly recommend comparing to serial/parallel gc with a huge 
> : eden and small survivor/small old gen is likely to have the same
> : performance with the following advantages:
> 
> But it still has some jitter in throughput time. I happen to work in
> a space where low latency is a premium, but the standard deviation pf
> the latency is also of value. We're willing to give up some of the
> mean and median performance in order to have a better six-sigma and
> maximum values.
> 
[...]
> On Fri, Dec 15, 2017 at 11:00:30AM +0100, Aleksey Shipilev wrote:
> : For example, Shenandoah with "passive" heuristics (which is a 
> : diagnostic mode, but might be interesting anyway) would disable 
> : concurrent phases, and rely only on Full GC to reclaim memory. In
> : return, it would not have any barriers enabled (including inter-
> : generational ones that serial/parallel would enable being 
> : unconditionally generational), and would not do GC until the very
> : last moment or until user asks for it with System.gc()....
> 
[...]
> 
> But in any case, I believe my comment was misplaced, because I agree
> with what Andrew Haley wrote on Fri, Dec 15, 2017 at 08:38:45AM
> +0000:
> : OK, but that is not one of the goals of Epsilon.  It's a reasonable
> : idea, but it's another project.
> 
> Yeah, for what I want I would have to propose Project Zeta.
> 
> Which would have to start by determining which GC method works best
> with "cooperative GC" (trying to play on "cooperative multitasking".

I think I understand your goals, but I am kind of unsure how such a
Zeta-Collector (btw, "Z" is now taken :)) could be any more hands-off
outside of actual GC than what you would achieve with using that
Shenandoah diagnostics mode or e.g. Serial and Parallel.

I assume you have been working on this, but this jitter may be
introduced from something else, and it may imho be more worthwhile to
determine the causes first - maybe using Epsilon if you think the
alternatives are not enough hands-off.

Thanks,
  Thomas

[prev in list] [next in list] [prev in thread] [next in thread]