src: track cppgc wrappers with CppgcWrapperList in Environment #56534

joyeecheung · 2025-01-09T16:56:38Z

This allows us to perform cleanups of cppgc wrappers that rely on a living Environment during Environment shutdown. Otherwise the cleanup may happen during object destruction, which can be triggered by GC after Enivronment shutdown, leading to invalid access to Environment.

The general pattern for this type of non-trivial destruction is designed to be:

class MyWrap final : CPPGC_MIXIN(MyWrap) {
 public:
  ~MyWrap() { this->Clean(); }
  void CleanEnvResource(Environment* env) override {
     // Do cleanup that relies on a living Environemnt. This would be
     // called by CppgcMixin::Clean() first during Environment shutdown,
     // while the Environment is still alive. If the destructor calls
     // Clean() again later during garbage collection that happens after
     // Environment shutdown, CleanEnvResource() would be skipped, preventing
     // invalid access to the Environment.
  }
}

In addition, this allows us to trace external memory held by the wrappers in the heap snapshots if we add synthethic edges between the wrappers and other nodes in the embdder graph callback, or to perform snapshot serialization for them.

src/cppgc_helpers.h

nodejs-github-bot · 2025-01-09T17:09:15Z

CI: https://ci.nodejs.org/job/node-test-pull-request/64424/

codecov · 2025-01-09T20:46:00Z

Codecov Report

Attention: Patch coverage is 91.66667% with 1 line in your changes missing coverage. Please review.

Project coverage is 89.10%. Comparing base (19c8cc1) to head (195a9a4).
Report is 90 commits behind head on main.

Files with missing lines	Patch %	Lines
src/cppgc_helpers.h	88.88%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #56534      +/-   ##
==========================================
- Coverage   89.16%   89.10%   -0.07%     
==========================================
  Files         662      660       -2     
  Lines      191745   191328     -417     
  Branches    36902    36775     -127     
==========================================
- Hits       170971   170477     -494     
- Misses      13627    13782     +155     
+ Partials     7147     7069      -78

Files with missing lines	Coverage Δ
src/env.cc	`85.76% <100.00%> (+0.09%)`	⬆️
src/env.h	`98.21% <100.00%> (+0.06%)`	⬆️
src/cppgc_helpers.h	`87.09% <88.88%> (+0.73%)`	⬆️

... and 56 files with indirect coverage changes

legendecas · 2025-01-10T10:36:14Z

src/README.md

+the `Environment` is already gone, it must implement the cleanup with this pattern:
+
+```c++
+  ~MyWrap() { this->Clean(); }


Assumptions should not be made about the order and the timing of their execution. There is no guarantee on the order in which the destructors are invoked. That's why destructors must not access any other on-heap objects (which might have already been destructed). If some destructor unavoidably needs to access other on-heap objects, it will have to be converted to a pre-finalizer. The pre-finalizer is allowed to access other on-heap objects.
https://github.com/v8/v8/tree/main/include/cppgc#sweeping-phase

This example should depend on CPPGC_USING_PRE_FINALIZER as it may access other heap objects.

Updated to mention CPPGC_USING_PRE_FINALIZER, though I noticed two things:

ContextifyContext does not even need to have special cleanup and can just have a default destructor - when the destructors are invoked, the context is already going away as it would've been holding the ContextifyContext alive. So there's no need to set the internal pointers of the context; On the other hand since the context is already going away, the per-environment context list would now contain empty global handles to that context, and the context tracking code is already able to deal with empty handles, so it matters little to purge it from the list in the destructor (we could also do the housekeeping in the constructor, in TrackContext() instead, to make sure there aren't too many empty handles lying around).

It seems the use of CPPGC_USING_PRE_FINALIZER would crash the construction of ContextifyContext, which I have not gotten to the bottom of yet.

This allows us to perform cleanups of cppgc wrappers that rely on a living Environment during Environment shutdown. Otherwise the cleanup may happen during object destruction, which can be triggered by GC after Enivronment shutdown, leading to invalid access to Environment. The general pattern for this type of non-trivial destruction is designed to be: ``` class MyWrap final : CPPGC_MIXIN(MyWrap) { public: ~MyWrap() { this->Clean(); } void CleanEnvResource(Environment* env) override { // Do cleanup that relies on a living Environemnt. This // would be called by CppgcMixin::Clean() first during // Environment shutdown, while the Environment is still // alive. If the destructor calls Clean() again later // during garbage collection that happens after // Environment shutdown, CleanEnvResource() would be // skipped, preventing invalid access to the Environment. } } ``` In addition, this allows us to iterate over the wrappers to trace external memory held by the wrappers in the heap snapshots if we add synthethic edges between the wrappers and other nodes in the embdder graph callback, or to perform snapshot serialization for them.

legendecas · 2025-01-21T15:17:04Z

src/README.md

+   ~MyWrap() { this->Clean(); }
+   void CleanEnvResource(Environment* env) override {
+     // Do cleanup that relies on a living Environemnt. This would be
+     // called by CppgcMixin::Clean() first during Environment shutdown,
+     // while the Environment is still alive. If the destructor calls
+     // Clean() again later during garbage collection that happens after
+     // Environment shutdown, CleanEnvResource() would be skipped, preventing
+     // invalid access to the Environment.
+   }


I'm still in doubt if this example will entice people to access handles on the node::Environment given that it is passed in as a parameter, and ultimately call this CleanEnvResource through the destructor, which is invoked by cppgc.

I'm wondering if we should avoid creating a cppgc object that is short-lived than its associated env resources.

Isn't the example in 3 enough to address this? I can remove Environment as a parameter though I don't think it makes much of a difference - people can still easily reach out to env() if they want, just like in the case of BaseObject's destructors, even if the destructors are called as the first pass weak callback.

Right, I think my comment was purely hypothetical.

nodejs-github-bot · 2025-01-23T10:44:31Z

CI: https://ci.nodejs.org/job/node-test-pull-request/64638/

jasnell · 2025-01-23T15:27:37Z

src/README.md

+the cleanups of a cppgc-managed object should adhere to different patterns,
+depending on what it needs to do:
+
+1. If it does not need to do any non-trivial, nor does its members, just use


sentence appears to be incomplete? Do any non-trivial what?

jasnell · 2025-01-23T15:28:49Z

src/README.md

+1. If it does not need to do any non-trivial, nor does its members, just use
+   the default destructor.
+2. If the cleanup relies on a living `Environment`, the class should use this
+   pattern in its class body:


This term "living Environment" is not defined. What is a living environment?

In this context, the term "living Enviroment" refers to a condition where a cppgc object can out-live its Environment as the cppgc heap is cleaned up after the Environment been destructed, as documented above:

When a cppgc-managed object is no longer reachable in the heap, its destructor
will be invoked by the garbage collection, which can happen after the Environment
is already gone.

Though, it didn't mention the term "living Environment".

Yeah, I know what was meant, but it should be explained a bit more in the document so that it is clear.

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. needs-ci PRs that need a full CI run. labels Jan 9, 2025

joyeecheung mentioned this pull request Jan 9, 2025

src: integrate ContextifyContext to cppgc #56522

Closed

joyeecheung added the request-ci Add this label to start a Jenkins CI on a PR. label Jan 9, 2025

legendecas reviewed Jan 9, 2025

View reviewed changes

src/cppgc_helpers.h Show resolved Hide resolved

github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jan 9, 2025

legendecas reviewed Jan 10, 2025

View reviewed changes

joyeecheung force-pushed the cppgc-list branch from 37e7bac to 195a9a4 Compare January 10, 2025 16:06

legendecas reviewed Jan 21, 2025

View reviewed changes

legendecas approved these changes Jan 23, 2025

View reviewed changes

legendecas added the request-ci Add this label to start a Jenkins CI on a PR. label Jan 23, 2025

github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jan 23, 2025

jasnell reviewed Jan 23, 2025

View reviewed changes

jasnell approved these changes Jan 23, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

src: track cppgc wrappers with CppgcWrapperList in Environment #56534

src: track cppgc wrappers with CppgcWrapperList in Environment #56534

joyeecheung commented Jan 9, 2025 •

edited

Loading

nodejs-github-bot commented Jan 9, 2025

codecov bot commented Jan 9, 2025 •

edited

Loading

legendecas Jan 10, 2025 •

edited

Loading

joyeecheung Jan 10, 2025

legendecas Jan 21, 2025

joyeecheung Jan 21, 2025 •

edited

Loading

legendecas Jan 23, 2025

nodejs-github-bot commented Jan 23, 2025

jasnell Jan 23, 2025

jasnell Jan 23, 2025

legendecas Jan 23, 2025

jasnell Jan 23, 2025

src: track cppgc wrappers with CppgcWrapperList in Environment #56534

Are you sure you want to change the base?

src: track cppgc wrappers with CppgcWrapperList in Environment #56534

Conversation

joyeecheung commented Jan 9, 2025 • edited Loading

nodejs-github-bot commented Jan 9, 2025

codecov bot commented Jan 9, 2025 • edited Loading

Codecov Report

legendecas Jan 10, 2025 • edited Loading

Choose a reason for hiding this comment

joyeecheung Jan 10, 2025

Choose a reason for hiding this comment

legendecas Jan 21, 2025

Choose a reason for hiding this comment

joyeecheung Jan 21, 2025 • edited Loading

Choose a reason for hiding this comment

legendecas Jan 23, 2025

Choose a reason for hiding this comment

nodejs-github-bot commented Jan 23, 2025

jasnell Jan 23, 2025

Choose a reason for hiding this comment

jasnell Jan 23, 2025

Choose a reason for hiding this comment

legendecas Jan 23, 2025

Choose a reason for hiding this comment

jasnell Jan 23, 2025

Choose a reason for hiding this comment

joyeecheung commented Jan 9, 2025 •

edited

Loading

codecov bot commented Jan 9, 2025 •

edited

Loading

legendecas Jan 10, 2025 •

edited

Loading

joyeecheung Jan 21, 2025 •

edited

Loading