Re: [v8-users] Memory leak on script crash

[Brendan Bates]

Just implemented the changes you suggested.  Works great and I will 
continue doing this in the future!  The memory
is WAY more stable and I now further understand the point of the 
ObjectTemplate now.  I did still report this in the issue
tracker, as I hope at least the effect of NewInstance() is documented (or 
made more visible if it already exists).

To Gautham B A, this problem can be solved by using an ObjectTemplate and 
persisting and reusing it instead of creating
a new one every time needed.

On Monday, May 1, 2017 at 11:41:46 AM UTC-4, Ben Noordhuis wrote:
>
> On Mon, May 1, 2017 at 5:20 PM, Brendan Bates <brendan...@gmail.com 
> > wrote: 
> > I have a question in response to this then.  How would you handle a 
> dynamic 
> > multi-indexed field mapped to a C++ object?  Currently we have a root 
> > ObjectTemplate with an 
> > indexed property handler that knows it is the first of three indices. 
>  The 
> > handler when requested will then generate a new ObjectTemplate with an 
> > indexed handler that knows it is the 
> > second of three indices, etc.  So yes, every call to "var test = 
> > data[1][2][3]" will generate three object templates as it goes up the 
> chain. 
>
> I'd create a single ObjectTemplate with one or more internal fields 
> for stashing data, cache the template in a Persistent 
> and instantiate it three times.  The indexed property handlers then 
> look at the internal fields to figure out what they should 
> access/return. 
>
> > As an aside to all of this - is this considered a bug?  I feel like if 
> not, 
> > the repercussions of this should be documented somewhere such as the 
> > NewInstance call in the v8 API. 
>
> I'm not a V8 maintainer so I can't answer this but to me it seems like 
> reasonable behavior.  The idea of a template is to share behavior 
> across multiple instances. 
>
> A CL updating include/v8.h to explain the memory ramifications will 
> almost certainly be accepted. 
>

-- 
-- 
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] Memory leak on script crash

[Brendan Bates]

>
> I'm not a V8 maintainer so I can't answer this but to me it seems like 
> reasonable behavior.  The idea of a template is to share behavior 
> across multiple instances. 
>

I guess the only reason I would consider it a bug: shouldn't any Javascript 
local/persistent be fully cleaned up when it goes out of
scope?  If you create the Local in a HandleScope and the 
scope closes, you can't use that template anymore.  I
would also think any metadata or cache related to that scope would clear as 
well.  I honestly don't know enough about v8 to make
that assumption, but I assumed most things stored in a Local were memory 
leak safe.

On Monday, May 1, 2017 at 11:41:46 AM UTC-4, Ben Noordhuis wrote:
>
> On Mon, May 1, 2017 at 5:20 PM, Brendan Bates <brendan...@gmail.com 
> > wrote: 
> > I have a question in response to this then.  How would you handle a 
> dynamic 
> > multi-indexed field mapped to a C++ object?  Currently we have a root 
> > ObjectTemplate with an 
> > indexed property handler that knows it is the first of three indices. 
>  The 
> > handler when requested will then generate a new ObjectTemplate with an 
> > indexed handler that knows it is the 
> > second of three indices, etc.  So yes, every call to "var test = 
> > data[1][2][3]" will generate three object templates as it goes up the 
> chain. 
>
> I'd create a single ObjectTemplate with one or more internal fields 
> for stashing data, cache the template in a Persistent 
> and instantiate it three times.  The indexed property handlers then 
> look at the internal fields to figure out what they should 
> access/return. 
>
> > As an aside to all of this - is this considered a bug?  I feel like if 
> not, 
> > the repercussions of this should be documented somewhere such as the 
> > NewInstance call in the v8 API. 
>
> I'm not a V8 maintainer so I can't answer this but to me it seems like 
> reasonable behavior.  The idea of a template is to share behavior 
> across multiple instances. 
>
> A CL updating include/v8.h to explain the memory ramifications will 
> almost certainly be accepted. 
>

-- 
-- 
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] Memory leak on script crash

[Brendan Bates]

Also @Gautham B A we have not figured out a good solution yet - still 
reviewing the best way to actually get around this.

On Monday, May 1, 2017 at 11:20:55 AM UTC-4, Brendan Bates wrote:
>
> Seems relevant enough to me if you like efficient programs
>>
>
> Oh I definitely agree it's important, just that the topic on hand isn't 
> necessarily the performance impact but the memory usage.  In our case, we 
> accept the performance
> impact for the flexibility of the solution.
>
>  It's not an issue when you create the ObjectTemplate once but it does 
>> become an issue when you create the ObjectTemplate afresh every time. 
>
>
> I have a question in response to this then.  How would you handle a 
> dynamic multi-indexed field mapped to a C++ object?  Currently we have a 
> root ObjectTemplate with an
> indexed property handler that knows it is the first of three indices.  The 
> handler when requested will then generate a new ObjectTemplate with an 
> indexed handler that knows it is the
> second of three indices, etc.  So yes, every call to "var test = 
> data[1][2][3]" will generate three object templates as it goes up the 
> chain.  Perhaps this is not possible/best use of v8, as a function call for 
> fetching the object could accomplish this.  However for our system, that is 
> less declarative than just using array notation.  Unfortunately a stock 
> object does not provide a way of setting an indexed property handler (as 
> far as I know).
>
> As an aside to all of this - is this considered a bug?  I feel like if 
> not, the repercussions of this should be documented somewhere such as the 
> NewInstance call in the v8 API.  I would not
> have caught this if we didn't run some stress tests on our system.  I 
> wrote a test that generates tens of MB per second (even when calling 
> LowMemoryNotification) from using this behavior.
>  
> On Monday, May 1, 2017 at 11:08:01 AM UTC-4, Ben Noordhuis wrote:
>>
>> On Mon, May 1, 2017 at 4:25 PM, Brendan Bates <brendan...@gmail.com> 
>> wrote: 
>> >> I don't see an actual memory leak in the code you posted but creating 
>> >> a new ObjectTemplate for every query isn't very efficient. 
>> > 
>> > Just wanted to reply to this to say, that is an irrelevant point to 
>> this 
>> > discussion.  Even if you are using it sparingly, if you have a 
>> long-running 
>> > script that calls NewInstance(), then 
>> > this would be a problem. 
>>
>> Seems relevant enough to me if you like efficient programs but I take 
>> back my words because there is a memory leak: ObjectTemplate::New() 
>> produces a template that caches instantiations.  The first 
>> instantiation is cached, subsequent instantiations are cloned from 
>> that cached instance. 
>>
>> It's not an issue when you create the ObjectTemplate once but it does 
>> become an issue when you create the ObjectTemplate afresh every time. 
>> That is a silly thing to do, though; it misses the point of templates. 
>>
>

-- 
-- 
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] Memory leak on script crash

[Brendan Bates]

>
> Seems relevant enough to me if you like efficient programs
>

Oh I definitely agree it's important, just that the topic on hand isn't 
necessarily the performance impact but the memory usage.  In our case, we 
accept the performance
impact for the flexibility of the solution.

 It's not an issue when you create the ObjectTemplate once but it does 
> become an issue when you create the ObjectTemplate afresh every time. 


I have a question in response to this then.  How would you handle a dynamic 
multi-indexed field mapped to a C++ object?  Currently we have a root 
ObjectTemplate with an
indexed property handler that knows it is the first of three indices.  The 
handler when requested will then generate a new ObjectTemplate with an 
indexed handler that knows it is the
second of three indices, etc.  So yes, every call to "var test = 
data[1][2][3]" will generate three object templates as it goes up the 
chain.  Perhaps this is not possible/best use of v8, as a function call for 
fetching the object could accomplish this.  However for our system, that is 
less declarative than just using array notation.  Unfortunately a stock 
object does not provide a way of setting an indexed property handler (as 
far as I know).

As an aside to all of this - is this considered a bug?  I feel like if not, 
the repercussions of this should be documented somewhere such as the 
NewInstance call in the v8 API.  I would not
have caught this if we didn't run some stress tests on our system.  I wrote 
a test that generates tens of MB per second (even when calling 
LowMemoryNotification) from using this behavior.
 
On Monday, May 1, 2017 at 11:08:01 AM UTC-4, Ben Noordhuis wrote:
>
> On Mon, May 1, 2017 at 4:25 PM, Brendan Bates <brendan...@gmail.com 
> > wrote: 
> >> I don't see an actual memory leak in the code you posted but creating 
> >> a new ObjectTemplate for every query isn't very efficient. 
> > 
> > Just wanted to reply to this to say, that is an irrelevant point to this 
> > discussion.  Even if you are using it sparingly, if you have a 
> long-running 
> > script that calls NewInstance(), then 
> > this would be a problem. 
>
> Seems relevant enough to me if you like efficient programs but I take 
> back my words because there is a memory leak: ObjectTemplate::New() 
> produces a template that caches instantiations.  The first 
> instantiation is cached, subsequent instantiations are cloned from 
> that cached instance. 
>
> It's not an issue when you create the ObjectTemplate once but it does 
> become an issue when you create the ObjectTemplate afresh every time. 
> That is a silly thing to do, though; it misses the point of templates. 
>

-- 
-- 
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] Memory leak on script crash

[Brendan Bates]

Hey Gautham B A,

I am currently experiencing a similar issue.  I have found that using 
NewInstance() causes a slow memory growth/leak in our application.  We 
aggressively call LowMemoryNotification() 
on our scripts, as they are meant to run for a very long time and accept 
the performance tradeoff.  This should theoretically clean up stray 
objects, but it seems that objects created via
NewInstance() are never properly marked for GC (maybe, I don't really know 
what's being held).  What's odd is that I can create a weak persistent 
beneath one of these objects, and they
get cleaned up regularly in the memory notification calls.

Are you still having issues?  I might make a test program and throw it on a 
gist and report back here.  I'd be curious as this doesn't seem like 
acceptable behavior for the engine.

I don't see an actual memory leak in the code you posted but creating 
> a new ObjectTemplate for every query isn't very efficient. 
>

Just wanted to reply to this to say, that is an irrelevant point to this 
discussion.  Even if you are using it sparingly, if you have a long-running 
script that calls NewInstance(), then
this would be a problem.

On Tuesday, April 18, 2017 at 5:27:59 AM UTC-4, Gautham B A wrote:
>
> Yes, the memory leak in this code isn't visible as it appears. 
> I observed the memory leak when I ran the "top" command. But when I 
> commented out the call to "NewInstance()", there wasn't any growth in 
> memory (which is obvious because there's nothing being created and passed 
> onto the JS world).
>
> On Tuesday, 18 April 2017 14:49:11 UTC+5:30, Ben Noordhuis wrote:
>>
>> On Tue, Apr 18, 2017 at 9:31 AM, Gautham B A 
>>  wrote: 
>> > Thank you Ben. 
>> > Yes, there's a try_catch.HasCaught() before running the script in order 
>> to 
>> > prevent the process from exiting. 
>> > Here's the code that will cause the script to run - 
>> > int SendUpdate(std::string value, std::string meta, 
>> >  std::string doc_type) { 
>> >   v8::Locker locker(GetIsolate()); 
>> >   v8::Isolate::Scope isolate_scope(GetIsolate()); 
>> >   v8::HandleScope handle_scope(GetIsolate()); 
>> > 
>> >   v8::Local context = 
>> >   v8::Local::New(GetIsolate(), context_); 
>> >   v8::Context::Scope context_scope(context); 
>> > 
>> >   v8::TryCatch try_catch(GetIsolate()); 
>> > 
>> >   v8::Handle args[2]; 
>> >   if (doc_type.compare("json") == 0) { 
>> > args[0] = 
>> > v8::JSON::Parse(v8::String::NewFromUtf8(GetIsolate(), 
>> > value.c_str())); 
>> >   } else { 
>> > args[0] = v8::String::NewFromUtf8(GetIsolate(), value.c_str()); 
>> >   } 
>> > 
>> >   args[1] = 
>> >   v8::JSON::Parse(v8::String::NewFromUtf8(GetIsolate(), 
>> meta.c_str())); 
>> > 
>> >   if (try_catch.HasCaught()) { 
>> > last_exception = ExceptionString(GetIsolate(), _catch); 
>> > LOG(logError) << "Last exception: " << last_exception << '\n'; 
>> >   } 
>> > 
>> >   v8::Local on_doc_update = 
>> >   v8::Local::New(GetIsolate(), on_update_); 
>> >   on_doc_update->Call(context->Global(), 2, args); 
>> > 
>> >   if (try_catch.HasCaught()) { 
>> > LOG(logDebug) << "Exception message: " 
>> >   << ExceptionString(GetIsolate(), _catch) << '\n'; 
>> > 
>> > return ON_UPDATE_CALL_FAIL; 
>> >   } 
>> > 
>> >   return SUCCESS; 
>> > } 
>> > 
>> > Is it possible to reclaim the memory without shutting the VM down? 
>>
>> Depends on what you mean by 'reclaim' and 'memory leak' - memory isn't 
>> reclaimed until the garbage collector deems it necessary.  People 
>> often mistake that for a memory leak when it is in fact the garbage 
>> collector doing its work (or rather, doing as little work as it can 
>> get away with.) 
>>
>> I don't see an actual memory leak in the code you posted but creating 
>> a new ObjectTemplate for every query isn't very efficient.  If you 
>> don't use ObjectTemplate features, replace it with Object::New(). 
>>
>

-- 
-- 
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] Re: Isolate Creation Times

[Brendan Bates]

Posted here: https://bugs.chromium.org/p/v8/issues/detail?id=6014.

Let me know if there are any other tests or information I can provide.

On Friday, February 24, 2017 at 1:04:02 AM UTC-5, Jochen Eisinger wrote:
>
> Hey
>
> That sounds odd. Could you file a bug at crbug.com/v8/new and provide the 
> gn args you used for building?
>
> Thanks
> Jochen
>
> Brendan Bates <brendan...@gmail.com > schrieb am Do., 23. 
> Feb. 2017, 18:07:
>
>> I should also note that I can replicate this by simply running the d8 
>> executable, which seems to take about 5 seconds to bootstrap.
>>
>>
>> On Thursday, February 23, 2017 at 10:59:47 AM UTC-5, Brendan Bates wrote:
>>>
>>> I'm posting here to see if anyone has experienced this recently.
>>>
>>> We upgraded our scripting environment from *5.1.281.65 *to *5.7.492.44*.  
>>> Everything as far as building with GN has gone 
>>> smoothly, however one odd issue is with the timing of the isolate 
>>> creation:
>>>
>>>
>>> _isolate = Isolate::New(createParams);
>>>
>>>
>>> This used to be nearly instantaneous (few ms at most), now it's taking 
>>> about 5 seconds on my Windows 10 64-bit 
>>> environment (with a 32-bit build).  The allocator in the createParams is 
>>> using the default v8 allocator.  Will using an
>>> empty snapshop help?  If we have 20 scripts loaded, that's 100 seconds 
>>> of startup time... way too much.  Any help
>>> would be appreciated.  Thanks!
>>>
>> -- 
>> -- 
>> v8-users mailing list
>> v8-u...@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+u...@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.

[v8-users] Re: Isolate Creation Times

[Brendan Bates]

I should also note that I can replicate this by simply running the d8 
executable, which seems to take about 5 seconds to bootstrap.

On Thursday, February 23, 2017 at 10:59:47 AM UTC-5, Brendan Bates wrote:
>
> I'm posting here to see if anyone has experienced this recently.
>
> We upgraded our scripting environment from *5.1.281.65 *to *5.7.492.44*. 
>  Everything as far as building with GN has gone 
> smoothly, however one odd issue is with the timing of the isolate creation:
>
>
> _isolate = Isolate::New(createParams);
>
>
> This used to be nearly instantaneous (few ms at most), now it's taking 
> about 5 seconds on my Windows 10 64-bit 
> environment (with a 32-bit build).  The allocator in the createParams is 
> using the default v8 allocator.  Will using an
> empty snapshop help?  If we have 20 scripts loaded, that's 100 seconds of 
> startup time... way too much.  Any help
> would be appreciated.  Thanks!
>

-- 
-- 
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] Isolate Creation Times

[Brendan Bates]

I'm posting here to see if anyone has experienced this recently.

We upgraded our scripting environment from *5.1.281.65 *to *5.7.492.44*. 
 Everything as far as building with GN has gone 
smoothly, however one odd issue is with the timing of the isolate creation:


_isolate = Isolate::New(createParams);


This used to be nearly instantaneous (few ms at most), now it's taking 
about 5 seconds on my Windows 10 64-bit 
environment (with a 32-bit build).  The allocator in the createParams is 
using the default v8 allocator.  Will using an
empty snapshop help?  If we have 20 scripts loaded, that's 100 seconds of 
startup time... way too much.  Any help
would be appreciated.  Thanks!

-- 
-- 
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] Re: Building with MSVC & GN - Where do the static files go?

[Brendan Bates]

Just tried this again in Win32 beta (5.7.492.44) it seems to work fine on a 
shared component build.  However, when I add the static library flag it 
doesn't seem to output anything useful unfortunately.  The DLL's are fine 
for now, I'm honestly just happy that I can get it building using GN with 
the latest versions.

On Wednesday, January 11, 2017 at 4:53:09 AM UTC-5, Hans Maier wrote:
>
> Ok, thanks for the Info. I will be using it as soon 5.7 becomes stable.
>
> Am Mittwoch, 11. Januar 2017 10:46:05 UTC+1 schrieb Jochen Eisinger:
>>
>> With the latest dev version of V8 (5.7), you should be able to get static 
>> libraries using the gn flag v8_static_library = true
>>
>> On Tue, Jan 10, 2017 at 4:26 PM Hans Maier <tbae...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I had the same issue. I ended up creating the static libs from the 
>>> obj-files using the MSVC lib tool manually.
>>>
>>> Unsatisfactory, but it was working for me.
>>>
>>> Am Montag, 9. Januar 2017 15:55:40 UTC+1 schrieb Brendan Bates:
>>>>
>>>> Hello,
>>>>
>>>> I have seen this issue pop up a couple times on here and wondering what 
>>>> the current status is.  I was spending the morning trying to get ahead of 
>>>> the game and switch from a Gyp build to a GN build.  We are using MSVC 
>>>> 2015 
>>>> to perform the build.  I am successfully configuring and building using 
>>>> the 
>>>> following commands:
>>>>
>>>> > gn gen out/x86.debug --args="is_debug=true v8_use_snapshot=false 
>>>> target_cpu=\"x86\" disable_libfuzzer=true"
>>>> Done. Made78 targets from 44 files in 1900ms
>>>>
>>>> > ninja-C out/x86.debug d8
>>>> ninja: Entering directory `out.gn/x86.debug'
>>>> [49/886] LINK mkpeephole.exe mkpeephole.exe.pdb
>>>> LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' 
>>>> specification
>>>> [886/886] LINK d8.exe d8.exe.pdb
>>>> LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' 
>>>> specification
>>>>
>>>> The build results are confusing, however.  In the "out" directory, I 
>>>> find the v8.dll, along with the icu*.dll files.  What seems to be missing 
>>>> are the static .lib files that were necessary in previous builds 
>>>> (v8_libbase.lib, v8_libplatform.lib and v8_nosnapshot.lib).  My build with 
>>>> new new v8 DLL does not seem to work without these.  So I attempted a 
>>>> static build, by adding the GN argument `is_component_build=false`.  To my 
>>>> surprise, no static libraries were generated at all!  Is this something 
>>>> that is planning on being supported in the future?  If not, what is the 
>>>> way 
>>>> around this?  I certainly don't want to transition my project to use GN.  
>>>> Thoughts?  Thanks in advance.
>>>>
>>> -- 
>>> -- 
>>> v8-users mailing list
>>> v8-u...@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+u...@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.

[v8-users] Building with MSVC & GN - Where do the static files go?

[Brendan Bates]

Hello,

I have seen this issue pop up a couple times on here and wondering what the 
current status is.  I was spending the morning trying to get ahead of the 
game and switch from a Gyp build to a GN build.  We are using MSVC 2015 to 
perform the build.  I am successfully configuring and building using the 
following commands:

> gn gen out/x86.debug --args="is_debug=true v8_use_snapshot=false 
target_cpu=\"x86\" disable_libfuzzer=true"
Done. Made78 targets from 44 files in 1900ms

> ninja-C out/x86.debug d8
ninja: Entering directory `out.gn/x86.debug'
[49/886] LINK mkpeephole.exe mkpeephole.exe.pdb
LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' 
specification
[886/886] LINK d8.exe d8.exe.pdb
LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' 
specification

The build results are confusing, however.  In the "out" directory, I find 
the v8.dll, along with the icu*.dll files.  What seems to be missing are 
the static .lib files that were necessary in previous builds 
(v8_libbase.lib, v8_libplatform.lib and v8_nosnapshot.lib).  My build with 
new new v8 DLL does not seem to work without these.  So I attempted a 
static build, by adding the GN argument `is_component_build=false`.  To my 
surprise, no static libraries were generated at all!  Is this something 
that is planning on being supported in the future?  If not, what is the way 
around this?  I certainly don't want to transition my project to use GN. 
 Thoughts?  Thanks in advance.

-- 
-- 
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] Re: Building with MSVC & GN - Where do the static files go?

[Brendan Bates]

I should also specify, this specific build is using the current Win32 
stable version 5.5.372.32.

-- 
-- 
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] Re: Library size when built with mingw

[Brendan Bates]

Update - Holy Guacamole, I've gotten v8 to build with MinGW!

Never thought I'd see this day come again.  I actually went a slightly 
different route with it - here are the things I changed:

   1. Apply the forking.py fix to depot_tools instead of v8.
   2. REMOVE lines 73 and 78 in the mingw-generate-makefiles.sh.  It now 
   shouldn't delete existing makefiles or call into the make routine.
   3. In the top-level Makefile, add the following after line 447:

./tools/mingw-generate-makefiles.sh

Now, you should be able to call the make command.  It will use Gyp to 
produce the proper makefiles, run the makefile patching script, then run 
the build.  I may be able to condense all of this (including the git 
patching) into a single bash file.  If I do this, I'll fork your repo and 
give it a try.

-- 
-- 
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] Re: Library size when built with mingw

[Brendan Bates]

I'm attempting using your fixes.  I've made some progress, had to change 
one thing so far.  The bundled Python is now moved out of the v8 folder and 
into the depot_tools folder.  I had to apply the "forking.py" patch in 
there.  All other patches seem to work.

I've hit one roadbloack, however.  When running the final make command to 
trigger the build, it regenerates the "Makefile.ia32.debug" makefile before 
it attempts a build.  As a result, all of the patches in that file are lost 
and the build fails:

make[1]: *** No rule to make target `../test\intl\intl.gyp`, needed by 
`Makefile.ia32.debug`.  Stop.

I'm trying to figure out what causes the makefile to regenerate, however 
I'm not too familiar with Gyp so I may not put too much time into this 
today.  I will post again if I can get further than this.  Thanks a ton for 
putting that up on Github - hopefully I can get somewhere with this!

On Thursday, May 12, 2016 at 1:00:39 AM UTC-4, Caleb Champlin wrote:
>
> I've put together a quick guide and patches for getting v8 building for 
> MinGW, available here: https://github.com/cchamplin/v8-mingw-guide. If 
> you want to test it and let me know that would be great. If everything 
> seems functional with the code changes I'll work on clean up and getting 
> them pushed upstream.
>
> Thanks
>
> On Wednesday, May 11, 2016 at 11:50:30 AM UTC-6, Brendan Bates wrote:
>>
>> Bummer, I figured so.  It seems as if MinGW support has been mostly 
>> abandoned at this point (not sure if it was ever really there to begin 
>> with).  Of course the IDE we use (JetBrains CLion) doesn't allow building 
>> with the MS toolchain.  If I ever do get around to toying with v8 and MinGW 
>> again I'll be sure to post here.
>>
>> On Wednesday, May 11, 2016 at 1:40:22 PM UTC-4, Zac Hansen wrote:
>>>
>>> Unfortunately no.   I gave up and went with the vs build.  I was happy 
>>> to be able to make it build with the actual 2015 tool chain so that was 
>>> nice.   It defaults to the 2013 toolchain.  
>>>
>>> On Wednesday, May 11, 2016, Brendan Bates <brendan...@gmail.com> wrote:
>>>
>>>> Hey Zac,
>>>>
>>>> I'm also trying to build on MinGW right now.  I have successfully built 
>>>> on MSVC2015 but would much prefer MinGW (as all of our other products run 
>>>> under MinGW in Windows).  I  have had no luck thus far, have you been able 
>>>> to successfully build yet?  I personally haven't got very far...
>>>>
>>>> On Friday, April 15, 2016 at 12:42:40 AM UTC-4, Zac Hansen wrote:
>>>>>
>>>>> I'm trying to do this right now and having a helluva time trying to 
>>>>> figure this out.
>>>>>
>>>>> Can you post the steps you took to get this far?   I ended up with 
>>>>> very large .a files on OS X (much larger than what you're seeing), but 
>>>>> the 
>>>>> linked binaries files were only ~35-40MB.  
>>>>>
>>>>> On Thursday, April 7, 2016 at 6:49:57 PM UTC-7, Caleb Champlin wrote:
>>>>>>
>>>>>> After more effort than I would have anticipated I finally got a new 
>>>>>> version of v8 (5.0) to build on mingw. I noticed however that 
>>>>>> v8lib_base.a 
>>>>>> is huge! Rougly 310MB.
>>>>>>
>>>>>> drwxr-xr-x1 x x  4096Apr  7 16:39 .
>>>>>> drwxr-xr-x1 x x  0 Apr  7 14:36 ..
>>>>>> -rw-r--r--   1 x x  322118626   Apr  7 16:19 libv8_base.a
>>>>>> -rw-r--r--   1 x x  252536Apr  7 16:22 libv8_libbase.a
>>>>>> -rw-r--r--   1 x x  690768Apr  7 16:22 libv8_libplatform.a
>>>>>> -rw-r--r--   1 x x  1033412  Apr  7 16:22 libv8_snapshot.a
>>>>>>
>>>>>> Here's how I built:
>>>>>>
>>>>>> GYPFLAGS="-Dv8_use_external_startup_data=0" CFLAGS=" -msse -msse2 
>>>>>> -msse3" CXXFLAGS=" -std=c++11 -msse -msse2 -msse3"  CFLAGS_host=" -msse 
>>>>>> -msse2 -msse3" CXXFLAGS_host=" -std=c++11 -msse -msse2 -msse3" make 
>>>>>> i18nsupport=off x64.release
>>>>>>
>>>>>>
>>>>>> I built as release, and I'm basically wondering if it's normal for 
>>>>>> the file to be this large. I was able to successfully link a Go 
>>>>>> application 
>>>>>> against and everything with V8 seemed to work f

[v8-users] Re: Library size when built with mingw

[Brendan Bates]

Hey Zac,

I'm also trying to build on MinGW right now.  I have successfully built on 
MSVC2015 but would much prefer MinGW (as all of our other products run 
under MinGW in Windows).  I  have had no luck thus far, have you been able 
to successfully build yet?  I personally haven't got very far...

On Friday, April 15, 2016 at 12:42:40 AM UTC-4, Zac Hansen wrote:
>
> I'm trying to do this right now and having a helluva time trying to figure 
> this out.
>
> Can you post the steps you took to get this far?   I ended up with very 
> large .a files on OS X (much larger than what you're seeing), but the 
> linked binaries files were only ~35-40MB.  
>
> On Thursday, April 7, 2016 at 6:49:57 PM UTC-7, Caleb Champlin wrote:
>>
>> After more effort than I would have anticipated I finally got a new 
>> version of v8 (5.0) to build on mingw. I noticed however that v8lib_base.a 
>> is huge! Rougly 310MB.
>>
>> drwxr-xr-x1 x x  4096Apr  7 16:39 .
>> drwxr-xr-x1 x x  0 Apr  7 14:36 ..
>> -rw-r--r--   1 x x  322118626   Apr  7 16:19 libv8_base.a
>> -rw-r--r--   1 x x  252536Apr  7 16:22 libv8_libbase.a
>> -rw-r--r--   1 x x  690768Apr  7 16:22 libv8_libplatform.a
>> -rw-r--r--   1 x x  1033412  Apr  7 16:22 libv8_snapshot.a
>>
>> Here's how I built:
>>
>> GYPFLAGS="-Dv8_use_external_startup_data=0" CFLAGS=" -msse -msse2 -msse3" 
>> CXXFLAGS=" -std=c++11 -msse -msse2 -msse3"  CFLAGS_host=" -msse -msse2 
>> -msse3" CXXFLAGS_host=" -std=c++11 -msse -msse2 -msse3" make 
>> i18nsupport=off x64.release
>>
>>
>> I built as release, and I'm basically wondering if it's normal for the 
>> file to be this large. I was able to successfully link a Go application 
>> against and everything with V8 seemed to work fine. 
>>
>>
>> Thanks.
>>
>

-- 
-- 
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.