[v8-users] What is required for the JS Environment to persist across script evaluations?

Currently using SpiderMonkey. Our application, in the course of operation, can evaluate many Javascript scripts over the course of a single run, and we preserve enough of the SpiderMonkey state between script executions to preserve all changes/additions to the base javascript environment.

Re: [v8-users] [novice] SIGSEGV upon entering new top of the stack context

I see! Thanks a lot for all the help :) On Fri, Dec 2, 2016 at 11:50 AM, Ben Noordhuis wrote: > On Fri, Dec 2, 2016 at 11:18 AM, Thomas Barusseau > wrote: > > Isn't there a simpler way, by the way, than using uv_async_send? > > Maybe not the answer

Re: [v8-users] [novice] SIGSEGV upon entering new top of the stack context

On Fri, Dec 2, 2016 at 11:18 AM, Thomas Barusseau wrote: > Isn't there a simpler way, by the way, than using uv_async_send? Maybe not the answer you're looking for but: don't use threads. :-) > I've seen in the documentation that there are Lockers/Unlockers. From what

Re: [v8-users] Minimizing v8 build size

Hi Matt, I was trying to make a v8 build(actually i need node, but node currently based on v8), and also need a small size, you said that you finally got 2.8 Mb, could you please tell me the detail of how to implement this? Thanks Carl 在 2014年8月29日星期五 UTC+8上午1:30:44，Matt Kline写道： > > Thank

Re: [v8-users] [novice] SIGSEGV upon entering new top of the stack context

Isn't there a simpler way, by the way, than using uv_async_send? I've seen in the documentation that there are Lockers/Unlockers. From what I've read they might be the things I need? Also, I decided to just pass around the pointer to Isolate since it shouldn't change anyway. So now doing this

Re: [v8-users] [novice] SIGSEGV upon entering new top of the stack context

Thanks a lot for your help, I'll look into that! On Fri, Dec 2, 2016 at 10:25 AM, Ben Noordhuis wrote: > On Fri, Dec 2, 2016 at 9:52 AM, Thomas Barusseau > wrote: > > So, anyway, I tried your fix. New errors/crashes arise. I believe it's > > because

Re: [v8-users] [novice] SIGSEGV upon entering new top of the stack context

On Fri, Dec 2, 2016 at 9:52 AM, Thomas Barusseau wrote: > So, anyway, I tried your fix. New errors/crashes arise. I believe it's > because of the > structure of my code, but here's what I do now : > > I put up the Local copying of the Persistent earlier, > and tried > to

Re: [v8-users] [novice] SIGSEGV upon entering new top of the stack context

So, anyway, I tried your fix. New errors/crashes arise. I believe it's because of the structure of my code, but here's what I do now : I put up the Local copying of the Persistent earlier, and tried to get its context the way you told me to. First of all, to copy it I had to define a

Re: [v8-users] [novice] SIGSEGV upon entering new top of the stack context

Let's assume that I can't wait for the VM to shut down. Do I have to fork the main node.js process itself? I suppose a simple fork in my node addon won't do much good... On Thursday, December 1, 2016 at 10:46:05 PM UTC+1, Ben Noordhuis wrote: > > On Thu, Dec 1, 2016 at 9:55 PM, Thomas Barusseau

Re: [v8-users] Segfault calling v8::Persistent::Reset.

Can you reproduce this and catch it in a debugger? Or run with ASAN enabled? On Fri, Dec 2, 2016 at 2:18 AM Jane Chen wrote: > Embedding v8 5.3. Seeing a segfault in our stress test: > > Critical: #6 0x7fbf3f6c0173 in > v8::internal::GlobalHandles::Node::Release() ()