RFC: Epsilon GC JEP

[Aleksey Shipilev]

Hi Erik,

I think we are coming to a consensus here.

Piece-wise:

On 07/18/2017 05:22 PM, Erik Helin wrote:
> That is not what I said. As I wrote above:
> 
>> but AFAIK almost all users prefer the slight
>> overhead of dirtying a card (and in return get a generational GC) for
>> the use cases where a single-gen mark-compact algorithm would be
>> applicable.
> 
> There are of course use cases for single-gen mark-sweep algorithms, and as I
> write above, for single-gen mark-compact algorithms as well. But for Java, and
> OpenJDK, at least it is my understanding that most users prefer a generational
> algorithm like Serial compared to a single-gen mark-compact algorithm (at least
> I have not seen a lot of users asking for that). But maybe I'm missing something
> here?

Mmm, "prefer" is not the same as "have no other option than trust JVM developers
that generational is better for their workloads, and having no energy to try to
build the collector proving otherwise". Because there is no no collector in
OpenJDK that avoids generational barriers. Saying "prefer" here is very very odd.

> No, I don't view it that way. Having the code in the upstream repository and
> having it exposed in binary builds are two very different things to me, and
> comes with very different requirements in terms of maintenance. If the code is
> in the upstream repository, then it is a tool for developers working in OpenJDK
> and for integrators building OpenJDK. We have a much easier time changing such
> code compared to code that users have come to rely on (and expect certain
> behavior from).

Okay. I am still quite a bit puzzled why "experimental" comes with any notion of
supportability, compatibility, testing coverage, etc. I don't think most of
current experimental options declared in globals.hpp come with that in mind. In
fact, many are even marked with "(Unsafe) (Unstable)"...


>> I hear you, but thing is, Epsilon does not seem a coding exercise anymore.
>> Epsilon is useful for GC performance work especially when readily available, and
>> there are willing users to adopt it. Similarly how we respect maintainers'
>> burden in the product, we have to also see what benefits users, especially the
>> ones who are championing our project performance even by cutting corners with
>> e.g. no-op GCs.
> 
> Yes, you always have to weigh the benefits against the costs, and in this case,
> exposing Epsilon GC to non-JVM developers seems, at least for now and to me,
> taht the benefits do not outweigh the costs. Who knows, maybe this will change
> and we redo the cost/benefit analysis? It is very easy to go from developer flag
> to experimental flag, it is way, way harder to go from experimental flag to
> developer flag.

Okay, that sounds like a compromise to me: push Epsilon under "develop" flag,
and then ask users or downstreams to switch it to "product" if they want. This
is not ideal, but it works. Does that resolve your concerns?

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20170718/b0007566/signature.asc>