Ticket #1875 (closed RFC: done)

Opened 4 years ago

Last modified 3 years ago

Deprecate "constant" PMCs.

Reported by: bacek Owned by: bacek
Priority: critical Milestone: 2.11
Component: GC Version: 2.10.0
Severity: fatal Keywords:
Cc: Language:
Patch status: Platform:

Description

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

Change History

  Changed 4 years ago by 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

  Changed 4 years ago by plobsing

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

follow-up: ↓ 4   Changed 4 years ago by 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?

in reply to: ↑ 3 ; follow-up: ↓ 5   Changed 4 years ago by 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

in reply to: ↑ 4 ; follow-up: ↓ 6   Changed 4 years ago by 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.

in reply to: ↑ 5   Changed 4 years ago by 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

follow-up: ↓ 9   Changed 4 years ago by 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.

follow-up: ↓ 10   Changed 4 years ago by 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.

in reply to: ↑ 7   Changed 4 years ago by 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

in reply to: ↑ 8   Changed 3 years ago by 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

  Changed 3 years ago by bacek

  • owner set to bacek

  Changed 3 years ago by bacek

  • status changed from new to closed
  • resolution set to done

Done.

Note: See TracTickets for help on using tickets.