Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename "log bit" to "log candidate bit" #1257

Open
wks opened this issue Jan 9, 2025 · 3 comments
Open

Rename "log bit" to "log candidate bit" #1257

wks opened this issue Jan 9, 2025 · 3 comments

Comments

@wks
Copy link
Collaborator

wks commented Jan 9, 2025

We have GLOBAL_LOG_BIT_SPEC, a per-object global metadata. It's The semantics is, when we apply write barrier to an object, and the metadata is 1 for an object, the write barrier will enter slow path, clear that bit, and log that object.

From the semantics, we can see that "1" actually means "not logged". So we have been using the term "unlogged bit" colloquially.

The same term was used in JikesRVM, too. The HeaderByte class defines the constants UNLOGGED_BIT and methods markAsLogged and markAsUnlogged. The two method names seem to avoid talking about "setting/clearing log bits" or "setting/clearing unlog bits", as if they were ambiguous.

I think even the term "unlogged bit" is bad, for two reasons.

Firstly, having the prefix "un-" in the name is confusing.

Secondly, and more importantly, if "unlogged" means "not logged", then all young objects should have the "unlogged bit" set to 1. But it is actually not. Young objects have 0 in their unlogged bits, but they are not logged. And when the object barrier is applied to the young object, they will still not be logged. Only mature objects can have 1 in their unlogged bits.

Proposal

I propose the new name "log candidate bit", or LogCand bit for short.

That what it is. If a object has LogCand bit 1, it is a candidate for logging, and the object barrier will log it. If it is 0, it is not a candidate, and will not be logged. It's sufficient and necessary.

For new objects, the LogCand bit is 0. It means it is not a candidate for logging, and of course it is not logged. After it is just promoted to the mature space, its LogCand bit becomes 1, bit it is still not logged. After the object is written into by the mutator, the barrier will set its LogCand back to 0, and log it. As we can see, being a "candidate of logging" or not is now decoupled from whether the object is "actually logged" or not. Therefore, "log candidate bit" makes more sense.

Alternative

"Loggable bit" is also OK, but I personally think "candidate" is more explicit.

"Log-enabled bit" also means the same thing.

We may further abbreviate "log candidate bit" to "LC bit" like we did for "VO bit". But GC developers may not be familiar with it. In the short term, we may just use the full name "log candidate bit".

@k-sareen
Copy link
Collaborator

k-sareen commented Jan 9, 2025

I disagree with this. unlog bit means 0 is logged and 1 is not logged (the reverse of a log bit). So when we flip the unlog bit for a mature object to 0, it actually means we are logging it. However, @steveblackburn mentioned that we should just use a simple log bit for this because the point of an unlog bit is to avoid having to flip bits in object headers. The idea then, with a simple log bit, is that we can just bulk initialize it to 1s for nursery objects and they will be 0s for mature objects until a mutator trips on a write barrier.

Essentially: A generational GC only takes logged objects into account. So all of the nursery objects + mature objects who have been logged.

@qinsoon
Copy link
Member

qinsoon commented Jan 9, 2025

You can call it log bit or unlog bit, depending on how you interpret it. But it is clear what we refer to when we say log/unlog bit. There is no point to introduce a new term that no one is familiar with.

@wks
Copy link
Collaborator Author

wks commented Jan 10, 2025

In today's meeting, @steveblackburn suggested not to change the name because the term "log bit" has been used on many published papers, and everyone is familiar with it. However, we can add comments to clarify its semantics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants