Ticket #607 (new roadmap)

Opened 13 years ago

Last modified 10 years ago

ordered destruction

Reported by: allison Owned by:
Priority: major Milestone: 2.11
Component: GC Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform: all


Extend or modify the existing GC and GC modules to allow ordered destruction (guarantee that the children of one PMC will all be destroyed before that PMC, etc).

Change History

Changed 12 years ago by chromatic

Note that dynpmcs with destroy() must be destroyed before the ParrotLibrary PMCs which represent their shared libraries (RT #46761).

Changed 11 years ago by dukeleto

  • priority changed from normal to major
  • platform set to all
  • component changed from none to GC

Just wanted to note that this issue causes nt/exit.t to coredump in Blikzkost's test suite. sorear++ and NotFound++ describe the issue in #parrot on 8.Sept.2010 :

<@sorear> dukeleto: Parrot has no concept of ordering in global destruction
<@sorear> dukeleto: blizkost SV proxies need to drop Perl-side references when destroyed
<@sorear> dukeleto: that means 1. blizkost needs to still be loaded 2. the Perl interpreter needs to still exist
<@NotFound> dukeleto: I suppose the problem is that it tries to destroy the sub that is calling exit.

Changed 11 years ago by jkeenan

  • milestone 3.6 deleted

Milestone 3.6 deleted

Changed 10 years ago by jkeenan

  • milestone set to 2.11

Can anyone an update on the status of this ticket?

Thank you very much.


Changed 10 years ago by bacek


I would like to close this bug as "wontfix". GCable objects can't be represented as acyclic graph in general case. So "children" of "some PMC" can be actually "parent" of same PMC. We do need different mechanism to support such behavior. E.g. "finalize"/"dispose" from JVM/CLR world.

-- Bacek

Note: See TracTickets for help on using tickets.