
Compact forwarding information for the Z Garbage Collector in the OpenJDK - pjmlp
https://inside.java/2020/06/25/compact-forwarding/
======
chrisseaton
I think this is the more accessible blog post version of the posted master
thesis.

[https://inside.java/2020/06/25/compact-
forwarding/](https://inside.java/2020/06/25/compact-forwarding/)

The context of this work is how you store the forwarding metadata for the ZGC
collector in the OpenJDK.

~~~
dang
Ok, changed from [https://www.diva-
portal.org/smash/get/diva2:1445578/FULLTEXT...](https://www.diva-
portal.org/smash/get/diva2:1445578/FULLTEXT01.pdf). Thanks!

------
rurban
I don't like extra forwarding tables, as it imposes a huge cache hit.

Forward pointers are only needed during a GC, so they very rare. Usually a
compacting GC tags the forwarding ptr as normal heap ptr, and just checks if
it needs to be forwarded or not. There are always at least 2 lower bits free
and one is enough. It's just one extra redirection and needs no extra
forwarding table lookup.

Also the extra table is pretty big. So not low memory overhead, rather
largish.

------
The_rationalist
I hope this GC will be able to signal deterministically when an object will be
free, getting destructors in java would be quite nice for checks and resources
cleanups

~~~
chrisseaton
Yikes I don't think anyone else wants this. Destructors (finalisers) are seen
as a pretty terrible mistake in Java. There is a better replacement that is
reference queues, but I think you want to think extremely hard before using
those as well. And no serious GC is going to be able to signal it
deterministically! In Java you should really manually clean up external
resources. Trying to get the GC to do it for you is never going to end well.
The GC doesn't guarantee to free any object at all.

~~~
The_rationalist
_are seen as a pretty terrible mistake in Java_ because of the limitation it
has with current GC. Having a method deterministically being called before
being freed is a feature that increase language expressiveness and that has no
inherent downside. So yes many devs would want that and you have failed to say
a reason for a dev to be "against" said feature. _In Java you should really
manually clean up external resources._ this is nuisible work that should be
automated and allow an error class that shouldn't exist (e.g forgetting to
close a file descriptor) How can this make sense to you? Things to say: Java
already has autocloseable which cover in big part the needs of a destructor.
It's just that it can't be used (I believe) for logging or behavior, only for
resource closing which limit expressiveness and observability.

 _And no serious GC is going to be able to signal it deterministically_ yes
this limitation is shared by all current GCs hence my point on a future GC.
The linked article make deterministic something that weren't before so my
comment is not HS.

 _The GC doesn 't guarantee to free any object at all._ If this is universal
to all GCs that exists and that will ever exists? Then how does autocloseable
work?

 _reference queues_ what is the difference with weak pointers?

~~~
chrisseaton
> you have failed to say a reason for a dev to be "against" said feature

Because as a developer I know we don't know how to implement it in a safe
reliable way. I want to write safe reliable code so I don't want to use this
feature.

> The linked article make deterministic something that weren't before so my
> comment is not HS.

That's not what the article means by 'deterministic', I'm afraid. They're
talking about it being deterministic at some point where the object is moved
to. It doesn't make anything temporally more deterministic.

> If this is universal to all GCs that exists and that will ever exists

I think it's pretty fair to say that nobody in the industry knows how to make
a reasonably high performance moving GC that is deterministic in when it frees
objects. Maybe someone will invent one one day? I wouldn't hold my breath.

> Then how does autocloseable work?

Something important to know is that AutoClosable has nothing at all to do with
the GC, so disregard that for this discussion. It just adds some code to be
called after a lexical block. It doesn't know anything about whether the
object is live or not.

> what is the difference with weak pointers?

Sorry not sure what this is asking - what is the difference between weak
pointers and... what?

Reference queues are at least in-band and run under programmer control, but
they're still non-deterministic in when (if!) a reference will be pushed to
the queue.

