Deprecate "constant" PMCs.

[bacek]

Hello.

Currently "constant" PMC/STRINGs are poor-man-generational-gc-old-objects. They are causing a lot of pain because requies very special handling on any stage of GC implementor (e.g. me). I propose to deprecate them all together.

This (probably) doesn't require deprecation cycle due pure internal usage of such "zombie PMCs".

-- Bacek

[bacek]

Hello.

Instead, we can provide flag for pmc_new like "this_pmc_will_live_forever" so GC implementors can use it as hint. But we still treat such PMCs as first-class citizens and properly mark them under normal flow.

-- Bacek

[plobsing]

+1 constant PMCs are more trouble than they are worth.

[nwellnhof]

+1 for treating constant objects like normal objects in GC. But why can't we simply keep the constant flag and ignore it in the GC code?

[bacek]

Replying to nwellnhof:

+1 for treating constant objects like normal objects in GC. But why can't we simply keep the constant flag and ignore it in the GC code?

This is what we have now. And this causing a lot of pain inside GC code.

-- Bacek

[nwellnhof]

Replying to bacek:

Replying to nwellnhof:

+1 for treating constant objects like normal objects in GC. But why can't we simply keep the constant flag and ignore it in the GC code?

This is what we have now. And this causing a lot of pain inside GC code.

I meant that we shouldn't treat constant PMCs differently in the GC code, but keep the flag in the rest of the code.

[bacek]

I meant that we shouldn't treat constant PMCs differently in the GC code, but keep the flag in the rest of the code.

Why to keep flag?

-- Bacek

[nwellnhof]

I'd keep the constant flag because it might be useful for another subsystem at a later point. But we should definitely separate "constant" PMCs and strings (whose contents don't change) from "permanent" PMCs (which are never destroyed). Only the latter should be relevant for GC. I'd also like to keep the constant_string_pool for constant string buffers. We should use the new permanent flag for that, though.

[cotto]

I'd rather not keep the constant flag around just because we might want to use it later. If it's useful right now, great. Otherwise let's rip it out properly and avoid keeping any vestigial bits in the codebase. Unused pieces make code harder to understand.

[bacek]

Replying to nwellnhof:

I'd keep the constant flag because it might be useful for another subsystem at a later point. But we should definitely separate "constant" PMCs and strings (whose contents don't change) from "permanent" PMCs (which are never destroyed). Only the latter should be relevant for GC. I'd also like to keep the constant_string_pool for constant string buffers. We should use the new permanent flag for that, though.

constant_string_pool is one the things I'm trying to get rid of. And +1 to cotto about properly kill it.

-- Bacek

[jkeenan]

Replying to cotto:

I'd rather not keep the constant flag around just because we might want to use it later. If it's useful right now, great. Otherwise let's rip it out properly and avoid keeping any vestigial bits in the codebase. Unused pieces make code harder to understand.

Do we have a plan to go forward with any of the changes discussed in this ticket?

Thank you very much.

kid51

[bacek]

Done.