Re: [v8-users] Re: Debugging wrapped C++ object
On Thu, May 10, 2018 at 11:18 AM, Anoop R. S. wrote: > Thank you for the reply, Ben. >> >> Instead of v8::IndexedPropertyHandlerConfiguration, you may >> want to use v8::NamedPropertyHandlerConfiguration. > > I am already using it. What I noticed is that, when I run the code without > devtools debugging, only the callback GenericNamedPropertyGetterCallback, > (of NamedPropertyHandlerConfiguration) is invoked. > IndexedPropertyHandlerConfiguration callbacks are not called even though > they are implemented. But when I run the code through the debugger, I can > see the IndexedPropertyHandlerConfiguration callback is called and whatever > I am populating inside it, is visible in the debugger. After that, > GenericNamedPropertyGetterCallback, (of NamedPropertyHandlerConfiguration) > is called, for resolving the names which I am putting into the array in > GenericNamedPropertyGetterCallback implementation. Just to make sure we're on the same page: IndexedPropertyHandlerConfiguration is for number-as-key operations, i.e., obj[42]; obj.x and obj['x'] on the other hand are named property operations. What the debugger does is (mostly) equivalent to `Object.keys(obj)` and `Object.getOwnPropertyNames(obj)`, operations that include enumerable element indices _and_ enumerable named properties in their output. That's why you observe your IndexedPropertyEnumeratorCallback getting invoked. It's asked to list the object's enumerable element indices. Interceptor callbacks need to conform to some fairly strict semantics (that isn't always explained well in v8.h), otherwise you can get unintuitive behavior. If unsure, take a look at test/cctest/test-api-interceptors.cc. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Any way to reset global object for context after context is created?
On Thu, May 10, 2018 at 10:24 PM, Jane Chen wrote: > Embedding v8 v5.3. > > Is there any way to reset global object for a context so that the context > can be re-used? > > How is Context::DetachGlobal() is meant to be used? > > Thanks, > Jane You can't reset a context but you can detach the global object and create a new context with it. It will revert to its pristine state in the new context. In a nutshell: auto global = old_context->Global(); old_context->Exit(); // Need to exit the context before detaching. old_context->DetachGlobal(); auto new_context = v8::Context::New(global->GetIsolate(), v8::Local(), global); -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[v8-users] Clarification on AllowJavascriptExecution
Hi Team,
We are using using node v6.9.0. We faced a crash, when there is a
javascript call being made from our app c++ code. Crash is happening
because, call is made within the DisallowJavascriptExecutionScope. This
scope is set in OptimizedCompileJob::GenerateCode() in compiler.cc.
Scenario is garbage collection is initiated from below code, which caused
some cleanup calls to be called from our app to javascript.
OptimizedCompileJob::Status OptimizedCompileJob::GenerateCode() {
DisallowJavascriptExecution no_js(isolate());
{
.
RegisterWeakObjectsInOptimizedCode() -> it is invoking garbage
collection, which landed up to the code in our app
..
}
}
Please clarify, during this time of operation, is it good to call our
javascript call with AllowJavaScriptExecutionScope. Will it have any side
effects?. Please clarify.
Thanks.
Regards,
Madan
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[v8-users] Concurrently locking isolate + entering exiting persistent context
I've been wondering if it's possible to concurrently use v8::Locker. I'm binding to v8 from a single-threaded language that uses fibers for concurrency (Crystal.) Since it's a single thread, v8::Locker is always instantly available. This seems fine, the bigger issue if with Context::Scope. I'm concurrently entering and exiting the same context from multiple fibers and I keep stumbling upon: # # Fatal error in v8::Context::Exit() # Cannot exit non-entered context # Which came to make sense to me. I'm passing around a pointer to a Persistent. In the function I concurrently access, I'm getting the Local from it (with the isolate) and creating a Context::Scope. The same Local might be exited more than once. I expect Enter is a noop if the Context has already been entered. My fix was to use a fiber-safe mutex to only allow one isolate locking and context scoping at any given time. Is this normal? Any way around it? -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Concurrently locking isolate + entering exiting persistent context
On Fri, May 11, 2018 at 7:36 PM, wrote: > I've been wondering if it's possible to concurrently use v8::Locker. > > I'm binding to v8 from a single-threaded language that uses fibers for > concurrency (Crystal.) Since it's a single thread, v8::Locker is always > instantly available. > > This seems fine, the bigger issue if with Context::Scope. > > I'm concurrently entering and exiting the same context from multiple fibers > and I keep stumbling upon: > > # > # Fatal error in v8::Context::Exit() > # Cannot exit non-entered context > # > > Which came to make sense to me. I'm passing around a pointer to a > Persistent. In the function I concurrently access, I'm getting the > Local from it (with the isolate) and creating a Context::Scope. The same > Local might be exited more than once. I expect Enter is a noop if > the Context has already been entered. It isn't. Enter() and Exit() calls need to match up. > My fix was to use a fiber-safe mutex to only allow one isolate locking and > context scoping at any given time. > > Is this normal? Any way around it? You may want to take a look at node-fibers. It uses a thread-local storage hack to trick V8 into supporting fibers. https://github.com/laverdet/node-fibers/blob/4786aef736ab8285d29e9476e3615abbd3935d37/src/coroutine.cc#L76-L123 -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Clarification on AllowJavascriptExecution
A DisallowJavascriptExecution scope indicates that the following code
relies on no JavaScript code being executed. If you execute JavaScript code
anyway, you will probably cause corruption and subsequent crashes or
misbehavior. The CHECK-failure exists to point out the problem early and in
an easy-to-understand fashion; overriding it with an
AllowJavascriptExecutionScope is like removing the "Danger! Minefield!"
warning sign before walking into a minefield.
You should probably keep a list of cleanup calls you want to make, and
execute them when the event loop gets back to you, rather than immediately.
On Fri, May 11, 2018 at 7:15 AM madana gopal
wrote:
> Hi Team,
>
> We are using using node v6.9.0. We faced a crash, when there is a
> javascript call being made from our app c++ code. Crash is happening
> because, call is made within the DisallowJavascriptExecutionScope. This
> scope is set in OptimizedCompileJob::GenerateCode() in compiler.cc.
> Scenario is garbage collection is initiated from below code, which caused
> some cleanup calls to be called from our app to javascript.
>
> OptimizedCompileJob::Status OptimizedCompileJob::GenerateCode() {
>
> DisallowJavascriptExecution no_js(isolate());
> {
>.
>RegisterWeakObjectsInOptimizedCode() -> it is invoking garbage
> collection, which landed up to the code in our app
>..
> }
> }
>
> Please clarify, during this time of operation, is it good to call our
> javascript call with AllowJavaScriptExecutionScope. Will it have any side
> effects?. Please clarify.
>
> Thanks.
>
> Regards,
> Madan
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Concurrently locking isolate + entering exiting persistent context
On Friday, May 11, 2018 at 2:45:06 PM UTC-4, Ben Noordhuis wrote:
>
> On Fri, May 11, 2018 at 7:36 PM, > wrote:
> > I've been wondering if it's possible to concurrently use v8::Locker.
> >
> > I'm binding to v8 from a single-threaded language that uses fibers for
> > concurrency (Crystal.) Since it's a single thread, v8::Locker is always
> > instantly available.
> >
> > This seems fine, the bigger issue if with Context::Scope.
> >
> > I'm concurrently entering and exiting the same context from multiple
> fibers
> > and I keep stumbling upon:
> >
> > #
> > # Fatal error in v8::Context::Exit()
> > # Cannot exit non-entered context
> > #
> >
> > Which came to make sense to me. I'm passing around a pointer to a
> > Persistent. In the function I concurrently access, I'm getting
> the
> > Local from it (with the isolate) and creating a Context::Scope. The same
> > Local might be exited more than once. I expect Enter is a noop
> if
> > the Context has already been entered.
>
> It isn't. Enter() and Exit() calls need to match up.
>
Yea, that makes sense. They do match up, but the function I use to get the
context handle may be called more than once at the same time. I mean, the
same context may be entered multiple times concurrently and exited at
different times. As soon as it's exited once by one of the concurrent
tasks, it will throw that error I pasted if it's exited again.
void __crystal_ctx_scoped(char *id);
void v8_with_ctx_scope(Isolate* iso, Context* ctxptr, char* id) {
v8::HandleScope handle_scope(iso);
v8::Local ctx = ctxptr->Get(iso);
{
v8::Context::Scope context_scope(ctx);
__crystal_ctx_scoped(id);
}
}
The __crystal_ctx_scoped is a callback exposed from Crystal to C. It
dispatches to the right context via the provided id.
I added the extra curly braces as a test, but I don't think they're
necessary.
> > My fix was to use a fiber-safe mutex to only allow one isolate locking
> and
> > context scoping at any given time.
> >
> > Is this normal? Any way around it?
>
> You may want to take a look at node-fibers. It uses a thread-local
> storage hack to trick V8 into supporting fibers.
>
>
> https://github.com/laverdet/node-fibers/blob/4786aef736ab8285d29e9476e3615abbd3935d37/src/coroutine.cc#L76-L123
>
>
>
>
I've looked at it a bit. I've also been chatting with its author.
I don't necessarily want fibers to work from within v8 (like node-fibers),
I mostly want to be able to call v8 from any fiber concurrently. But maybe
the requirements for that are similar.
I'm already assigning the stack limit to the stack_bottom (or top depending
on who you're talking to) + padding to the isolate on after each lock.
Apparently that's not enough and it somehow started crashing a bit.
Discussing with the node-fibers authors on maybe fixing that.
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Concurrently locking isolate + entering exiting persistent context
On Fri, May 11, 2018 at 10:05 PM, wrote:
> Yea, that makes sense. They do match up, but the function I use to get the
> context handle may be called more than once at the same time. I mean, the
> same context may be entered multiple times concurrently and exited at
> different times. As soon as it's exited once by one of the concurrent tasks,
> it will throw that error I pasted if it's exited again.
>
> void __crystal_ctx_scoped(char *id);
>
> void v8_with_ctx_scope(Isolate* iso, Context* ctxptr, char* id) {
> v8::HandleScope handle_scope(iso);
> v8::Local ctx = ctxptr->Get(iso);
> {
> v8::Context::Scope context_scope(ctx);
> __crystal_ctx_scoped(id);
> }
> }
>
> The __crystal_ctx_scoped is a callback exposed from Crystal to C. It
> dispatches to the right context via the provided id.
You mean __crystal_ctx_scoped() directly or indirectly calls
v8_with_ctx_scope() again? Yes, that's going to be problematic.
At what point or points do you call into V8? You could maintain a
stack of contexts and call Enter() and Exit() manually but that only
works when there are no V8 stack frames (either JS or C++) on the call
stack.
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Concurrently locking isolate + entering exiting persistent context
On May 11, 2018 at 4:36:12 PM, Ben Noordhuis (i...@bnoordhuis.nl) wrote:
On Fri, May 11, 2018 at 10:05 PM, wrote:
> Yea, that makes sense. They do match up, but the function I use to get the
> context handle may be called more than once at the same time. I mean, the
> same context may be entered multiple times concurrently and exited at
> different times. As soon as it's exited once by one of the concurrent
tasks,
> it will throw that error I pasted if it's exited again.
>
> void __crystal_ctx_scoped(char *id);
>
> void v8_with_ctx_scope(Isolate* iso, Context* ctxptr, char* id) {
> v8::HandleScope handle_scope(iso);
> v8::Local ctx = ctxptr->Get(iso);
> {
> v8::Context::Scope context_scope(ctx);
> __crystal_ctx_scoped(id);
> }
> }
>
> The __crystal_ctx_scoped is a callback exposed from Crystal to C. It
> dispatches to the right context via the provided id.
You mean __crystal_ctx_scoped() directly or indirectly calls
v8_with_ctx_scope() again? Yes, that's going to be problematic.
Another fiber might call v8_with_ctx_scope() again before the first call to
it is done. With the same context. When I added a mutex, the problem seemed
fixed. I just want to make sure this is limitation: you can't enter the
same context more than one at the same time, or else exiting will exit from
both "enters".
At what point or points do you call into V8? You could maintain a
stack of contexts and call Enter() and Exit() manually but that only
works when there are no V8 stack frames (either JS or C++) on the call
stack.
Hmm. It's called into when there's an HTTP request coming in or when
there's a callback fired (like a setTimeout.)
Not entirely sure what kind of information you're looking for :) There's
probably going to be frames on the call stack.
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to a topic in the
Google Groups "v8-users" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/v8-users/5EbYZlO5VTY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Clarification on AllowJavascriptExecution
Thanks Jakob. Below is the backtrace. Here how can I identify, when I came out of event loop. Because, we want cleanup calls to get called quickly. *Backtrace:* V8_Fatal 0x5ac3ec3 v8::Function::NewInstance(v8::Local, int, v8::Local*) const* // calling javascript function here* // app code v8::internal::GlobalHandles::PendingPhantomCallback::Invoke(v8::internal::Isolate*) v8::internal::GlobalHandles::DispatchPendingPhantomCallbacks(bool) v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::internal::GarbageCollector, v8::GCCallbackFlags) v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, char const*, char const*, v8::GCCallbackFlags) v8::internal::Factory::CopyFixedArrayAndGrow(v8::internal::Handle, int, v8::internal::PretenureFlag) v8::internal::ArrayList::EnsureSpace(v8::internal::Handle, int) v8::internal::ArrayList::Add(v8::internal::Handle, v8::internal::Handle, v8::internal::Handle, v8::internal::ArrayList::AddMode) v8::internal::Heap::AddRetainedMap(v8::internal::Handle) 0x59d0eda v8::internal::OptimizedCompileJob::GenerateCode() *//DisAllowJavascriptExecutionScope set here* v8::internal::Compiler::FinalizeOptimizedCompileJob(v8::internal::OptimizedCompileJob*) v8::internal::OptimizingCompileDispatcher::InstallOptimizedFunctions() v8::internal::Runtime_TryInstallOptimizedCode(int, v8::internal::Object**, v8::internal::Isolate*) We have many number of cleanup objects, for which we have to call JS code on it being garbage collected. So, we will have cleanup calls for every object being garbage collected. Could you please point the instant, at which it will be good to identify this operation is completed (i.e the point where JS enging completed its garbage collection operation and we are good to do cleanup). Thanks. Regards, Madan -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Clarification on AllowJavascriptExecution
It's not about the garbage collection operation being completed. Presumably you have a call to v8::Script::Run() somewhere? When that call returns, you can safely execute other scripts. On Fri, May 11, 2018 at 5:01 PM madana gopal wrote: > Thanks Jakob. > > Below is the backtrace. Here how can I identify, when I came out of event > loop. Because, we want cleanup calls to get called quickly. > > *Backtrace:* > > V8_Fatal > 0x5ac3ec3 > v8::Function::NewInstance(v8::Local, int, > v8::Local*) const* // calling javascript function here* > // app code > > v8::internal::GlobalHandles::PendingPhantomCallback::Invoke(v8::internal::Isolate*) > v8::internal::GlobalHandles::DispatchPendingPhantomCallbacks(bool) > v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::internal::GarbageCollector, > v8::GCCallbackFlags) > v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, > v8::GCCallbackFlags) > v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, char > const*, char const*, v8::GCCallbackFlags) > v8::internal::Factory::CopyFixedArrayAndGrow(v8::internal::Handle, > int, v8::internal::PretenureFlag) > v8::internal::ArrayList::EnsureSpace(v8::internal::Handle, > int) > v8::internal::ArrayList::Add(v8::internal::Handle, > v8::internal::Handle, > v8::internal::Handle, > v8::internal::ArrayList::AddMode) > v8::internal::Heap::AddRetainedMap(v8::internal::Handle) > 0x59d0eda > v8::internal::OptimizedCompileJob::GenerateCode() > *//DisAllowJavascriptExecutionScope > set here* > > v8::internal::Compiler::FinalizeOptimizedCompileJob(v8::internal::OptimizedCompileJob*) > v8::internal::OptimizingCompileDispatcher::InstallOptimizedFunctions() > v8::internal::Runtime_TryInstallOptimizedCode(int, v8::internal::Object**, > v8::internal::Isolate*) > > > We have many number of cleanup objects, for which we have to call JS code > on it being garbage collected. So, we will have cleanup calls for every > object being garbage collected. Could you please point the instant, at > which it will be good to identify this operation is completed (i.e the > point where JS enging completed its garbage collection operation and we are > good to do cleanup). > > Thanks. > > Regards, > Madan > > -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Clarification on AllowJavascriptExecution
> > Thanks, ok. let me go through and update. We have both Script.Run() calls and vm.runScript() calls in our project. So, we have to make sure, we are not making any JS calls, when either Run() or vm.runScript() going on (as they will involve in code compilation) and need to wait for its completion. Is my understanding right Jakob? Thanks. Regards, Madan -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Any way to reset global object for context after context is created?
Thanks Ben.
I want to re-use my context for performance reasons, but some JavaScript
programs have constant global variables that cannot be re-defined, such as
those declared with let or const. To work around this, I thought I could
just evaluate each program in a closure by artificially enclosing the
script with {}. Do you see any issue with doing it? Is there any better
way to do so?
On Friday, May 11, 2018 at 5:50:07 AM UTC-7, Ben Noordhuis wrote:
>
> On Thu, May 10, 2018 at 10:24 PM, Jane Chen > wrote:
> > Embedding v8 v5.3.
> >
> > Is there any way to reset global object for a context so that the
> context
> > can be re-used?
> >
> > How is Context::DetachGlobal() is meant to be used?
> >
> > Thanks,
> > Jane
>
> You can't reset a context but you can detach the global object and
> create a new context with it. It will revert to its pristine state in
> the new context. In a nutshell:
>
> auto global = old_context->Global();
> old_context->Exit(); // Need to exit the context before detaching.
> old_context->DetachGlobal();
> auto new_context = v8::Context::New(global->GetIsolate(),
> v8::Local(), global);
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
