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

Meta: Heap traversal and dumping #803

Open
wks opened this issue May 5, 2023 · 0 comments
Open

Meta: Heap traversal and dumping #803

wks opened this issue May 5, 2023 · 0 comments
Labels
C-feature Category: Feature P-normal Priority: Normal.

Comments

@wks
Copy link
Collaborator

wks commented May 5, 2023

Requirements

There are requirements for heap traversal / heap dumping / object dumping:

  • by GC developers
    • in production setting
      • Some GC algorithms need to enumerate live objects. For example, MarkCompact enumerates live objects in the MarkCompactSpace to compact objects.
    • for debugging
  • by VMs
    • Related issue: API for enumerating objects #795
    • All allocated objects (reachable or not, in no particular order)
    • Subgraph (from given objects or from roots)
      • Ruby:
        • ObjectSpace.dump(obj) (from given obj)
        • ObjectSpace.dump_all (from roots)
        • rb_ractor_make_shareable
        • rb_objspace_reachable_objects_from
        • rb_objspace_reachable_objects_from_root
      • JVM TI: FollowReferences (from given object or all roots, depending on parameter)

Traversal mode

This is about both implementation and the API. Some requirements (such as ObjectSpace.each_object) can only be implemented in one way or another. Others (such as debugging) can use either way.

  • Global / space-local metadata
    • Enumerating all objects using VO-bit
      • This method may visit dead (but not yet reclaimed) objects.
    • Enumerating objects in MarkCompactSpace using local metadata
  • Transitive closure
    • From given object
    • From roots
      • This method only visits reachable objects from roots, but not dead (but not yet reclaimed) objects.

Time

Whether it happens at mutator time or GC time will have an impact on the implementation, such as synchornisation or the possibility of missing any newly allocated objects.

  • At GC time
    • MarkCompact
      • during forwarding. The Plan is in total control of synchronisation.
    • Debugging
      • just before GC (all objects are in from-space)
      • just after GC (all objects are in to-space)
      • as we compute transitive closure (some objects are not yet moved while others are. Beware of inconsistent state!)
  • At mutator time
    • whole-heap traversal (may miss some objects)
    • subgraph traversal (relatively deterministic unless other mutator threads interfere)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature Category: Feature P-normal Priority: Normal.
Projects
None yet
Development

No branches or pull requests

2 participants