-
Notifications
You must be signed in to change notification settings - Fork 30.7k
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
src: invoke per-isolate setters earlier #25608
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,6 +19,7 @@ | |
// OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE | ||
// USE OR OTHER DEALINGS IN THE SOFTWARE. | ||
|
||
#include "module_wrap.h" | ||
#include "node_binding.h" | ||
#include "node_buffer.h" | ||
#include "node_constants.h" | ||
|
@@ -1380,7 +1381,19 @@ Isolate* NewIsolate(ArrayBufferAllocator* allocator, uv_loop_t* event_loop) { | |
isolate->SetFatalErrorHandler(OnFatalError); | ||
isolate->SetAllowWasmCodeGenerationCallback(AllowWasmCodeGenerationCallback); | ||
v8::CpuProfiler::UseDetailedSourcePositionsForProfiling(isolate); | ||
isolate->SetPromiseRejectCallback(task_queue::PromiseRejectCallback); | ||
|
||
// NOTE: the following two callbacks currently CHECKs that the isolates | ||
// have associated environments. | ||
isolate->SetHostInitializeImportMetaObjectCallback( | ||
loader::ModuleWrap::HostInitializeImportMetaObjectCallback); | ||
isolate->SetHostImportModuleDynamicallyCallback( | ||
loader::ModuleWrap::ImportModuleDynamically); | ||
|
||
#if defined HAVE_DTRACE || defined HAVE_ETW | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since you're here: |
||
isolate->AddGCPrologueCallback(DTraceGCStartCallback); | ||
isolate->AddGCEpilogueCallback(DTraceGCEndCallback); | ||
#endif | ||
return isolate; | ||
} | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -290,14 +290,6 @@ void MarkGarbageCollectionEnd(Isolate* isolate, | |
entry); | ||
} | ||
|
||
|
||
inline void SetupGarbageCollectionTracking(Environment* env) { | ||
env->isolate()->AddGCPrologueCallback(MarkGarbageCollectionStart, | ||
static_cast<void*>(env)); | ||
env->isolate()->AddGCEpilogueCallback(MarkGarbageCollectionEnd, | ||
static_cast<void*>(env)); | ||
} | ||
|
||
// Gets the name of a function | ||
inline Local<Value> GetName(Local<Function> fn) { | ||
Local<Value> val = fn->GetDebugName(); | ||
|
@@ -440,8 +432,6 @@ void Initialize(Local<Object> target, | |
env->constants_string(), | ||
constants, | ||
attr).ToChecked(); | ||
|
||
SetupGarbageCollectionTracking(env); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would actually prefer for this to stay here. It makes the code more local and more obvious to me, and only adds the callbacks when they are actually used. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @addaleax this is currently unconditionally called when the isolate goes through bootstrapping - maybe this should be delayed until the first time the user adds an There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @joyeecheung If that’s feasible, it sounds good to me, but I’m more worried about code organization than performance. Also, I’m just noticing that we never remove these listeners … that’s a bug that we should fix if we can? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See #25647 – I’m happy to close it if you want to do sth in this PR :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
} | ||
|
||
} // namespace performance | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not entirely sure if we should do this here, or in
Environment
constructor, since these two callbacks do not handle the cases when the isolates' current context does not have Environments associated. Does it make sense to simply crash if the user tries to accessimport()
orimport.meta
from a context without an associated environment? Or should we return an empty Maybe/do nothing in the callbacks instead? Or should we postpone this to the Environment initialization? (But then the Environments would control per-isolate states)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It’s tricky… I think for now crashing is okay (and the best we can do), and anything more would require interaction with embedders (which would be the main source for this not working).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think these esm ones should have been moved. they are set in response to core opting into handling them. if the handlers don't get attached, we shouldn't have these handlers enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I agree with @devsnek. Embedders can install their own after the call to
NewIsolate()
.