[v8-users] What C++ language standard for V8?

[Thomson Tan]

As V8 is written mostly in C++, what standard does it obey, C++11, or later?

-- 
-- 
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] Non-msvc LIBC for Windows build?

[Thomson Tan]

What does it mean for not supported? Cannot build V8 with MinGW on Windows?

On Tuesday, April 17, 2018 at 11:17:50 AM UTC-7, Ben Noordhuis wrote:
>
> On Tue, Apr 17, 2018 at 7:49 PM, Thomson Tan  > wrote: 
> > There is a macro V8_LIBC_MSVCRT. Does it imply Windows build of V8 
> always 
> > depends on MSVC LIBC? How about building via Clang on Windows? 
>
> Clang still links against the MS CRT.  If you were thinking of MinGW: 
> that's not supported. 
>

-- 
-- 
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] Is running a v8 instance built as a static library supported in the same process that loaded a different v8 instance in a DLL?

[Jakob Kummerow]

>
> > What Ben pointed out was virtual memory reservations, which is not the
> same as restricted space sizes.
>
> Would you guys mind expanding on this? My thinking is that the v8 commits
> as much memory as it is allowed for semi/old/code spaces (considering that
> the app doesn't allocate more than fits into these spaces), plus for the
> C++ machinery to maintain these objects and if those sizes are limited to
> some reasonable size, why would v8 reserve more memory that it cannot
> commit?
>

Memory address space is separate from actual memory. There are cases where
it makes sense to reserve a large chunk of address space without requesting
it to be backed by actual memory, usually when a contiguous range may be
required later.
For example, on 64-bit platforms, V8 requires all executable memory to be
within a 2GB section of address space so that calls can use 32-bit offsets,
so it reserves that amount of address space on initialization (which is a
very cheap operation), whereas actual memory is allocated later as needed.
WebAssembly has a similar use case where a large section of address space
is reserved so that *if* it needs to use that memory later, the addresses
will be contiguous.

-- 
-- 
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] Is running a v8 instance built as a static library supported in the same process that loaded a different v8 instance in a DLL?

[A.M.]

 Great. Thank you for jumping in, Jakob. Considering that both, you and Ben 
didn't reject this approach with some obvious reason, like some resources 
created with a process ID in the name, I can go ahead and try things out 
with a static v8 build. Without the input from the both of you, a simple 
working test wouldn't be worth much.

> What Ben pointed out was virtual memory reservations, which is not the 
same as restricted space sizes.

Would you guys mind expanding on this? My thinking is that the v8 commits 
as much memory as it is allowed for semi/old/code spaces (considering that 
the app doesn't allocate more than fits into these spaces), plus for the 
C++ machinery to maintain these objects and if those sizes are limited to 
some reasonable size, why would v8 reserve more memory that it cannot 
commit?

-- 
-- 
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] Is running a v8 instance built as a static library supported in the same process that loaded a different v8 instance in a DLL?

[A.M.]

Great. Thank you for jumping in, Jakob. Considering that both, you and Ben 
didn't reject this approach with some obvious reason, like some resources 
created with a process ID in the name, I can go ahead and try things out 
with a static v8 build. Without the input from the both of you, a simple 
working test wouldn't worth much.

> What Ben pointed out was virtual memory reservations, which is not the 
same as restricted space sizes.

Would you guys mind expanding on this? My thinking is that the v8 commits 
as much memory as it is allowed for semi/old/code spaces (considering that 
the app doesn't allocate more than fits into these spaces), plus for the 
C++ machinery to maintain these objects and if those sizes are limited to 
some reasonable size, why would v8 reserve more memory that it cannot 
commit?

-- 
-- 
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] Is running a v8 instance built as a static library supported in the same process that loaded a different v8 instance in a DLL?

[Jakob Kummerow]

I'm on the V8 team, and I defer to Ben on this question :-)

I've never tried embedding two different versions of V8 into the same
process, and I don't think we'd consider that scenario supported, but it
may well work. You can probably find out with a fairly small example (i.e.
without sinking lots of time into it) whether it works.

With regards to memory, I implemented first/second chance weak handle
> callbacks and tested it with low memory limits for semi/old space sizes and
> it appears to deal with memory restrictions well.


What Ben pointed out was virtual memory reservations, which is not the same
as restricted space sizes. As he said, on 64-bit platforms it shouldn't be
a problem.

-- 
-- 
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] Is running a v8 instance built as a static library supported in the same process that loaded a different v8 instance in a DLL?

[A.M.]

Thanks Ben. Your feedback is much appreciated. I realize you are not on the 
v8 team. Just thought may be I'm missing some MSDN-like way to contact 
Google.

-- 
-- 
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] Non-msvc LIBC for Windows build?

[Ben Noordhuis]

On Tue, Apr 17, 2018 at 7:49 PM, Thomson Tan  wrote:
> There is a macro V8_LIBC_MSVCRT. Does it imply Windows build of V8 always
> depends on MSVC LIBC? How about building via Clang on Windows?

Clang still links against the MS CRT.  If you were thinking of MinGW:
that's not supported.

-- 
-- 
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] Is running a v8 instance built as a static library supported in the same process that loaded a different v8 instance in a DLL?

[Ben Noordhuis]

On Tue, Apr 17, 2018 at 4:31 PM, A.M.  wrote:
> Thank you, Ben. That is reassuring. With regards to memory, I implemented
> first/second chance weak handle callbacks and tested it with low memory
> limits for semi/old space sizes and it appears to deal with memory
> restrictions well.
>
> The project I'm working on is rather large and it would be really helpful if
> there was a way to get some feedback from the v8 team. Do you know if there
> is a way to get in touch with somebody from the v8 team?

I'm not on the V8 team so I can't really say but I expect
"self-support" sums it up.  If you have questions, this mailing list
is probably the best place to ask them.

-- 
-- 
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] Non-msvc LIBC for Windows build?

[Thomson Tan]

There is a macro V8_LIBC_MSVCRT. Does it imply Windows build of V8 always 
depends on MSVC LIBC? How about building via Clang on Windows?

-- 
-- 
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] Is running a v8 instance built as a static library supported in the same process that loaded a different v8 instance in a DLL?

[A.M.]

Thank you, Ben. That is reassuring. With regards to memory, I implemented 
first/second chance weak handle callbacks and tested it with low memory 
limits for semi/old space sizes and it appears to deal with memory 
restrictions well. 

The project I'm working on is rather large and it would be really helpful 
if there was a way to get some feedback from the v8 team. Do you know if 
there is a way to get in touch with somebody from the v8 team? 

-- 
-- 
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: Unresolved Win32 entry points

[Bit Cortex]

Fixed. I was trying to build 64-bit V8 in a Visual Studio command prompt 
configured for 32-bit targets.

On Sunday, April 15, 2018 at 3:54:19 PM UTC-4, Bit Cortex wrote:
>
> Hello!
>
> I'm trying to build the 6.6 branch tip for WIndows. After installing 
> depot_tools, I run the following commands in a Visual Studio 2017 prompt:
>
> set DEPOT_TOOLS_WIN_TOOLCHAIN=0
> gclient config https://chromium.googlesource.com/v8/v8
> gclient sync -r 6.6.346.24
> cd v8
> gn gen out --args="is_debug=false v8_use_snapshot=true 
> v8_use_external_startup_data=false v8_enable_i18n_support=false"
> ninja -C out
>
> Everything goes well until the final step, where the LINK tasks fail to 
> resolve the Win32 entry points. Partial output:
>
> >ninja -C out
> ninja: Entering directory `out'
> [639/1119] LINK mksnapshot.exe mksnapshot.exe.pdb
> FAILED: mksnapshot.exe mksnapshot.exe.pdb
> c:/Code/v8/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe 
> ../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False 
> link.exe /nologo /OUT:./mksnapshot.exe /PDB:./mksnapshot.exe.pdb 
> @./mksnapshot.exe.rsp
> sampler.obj : error LNK2019: unresolved external symbol 
> __imp_GetCurrentThreadId referenced in function "public: __cdecl 
> v8::sampler::Sampler::Sampler(class v8::Isolate *)" 
> (??0Sampler@sampler@v8@@QEAA@PEAVIsolate@2@@Z)
> v8_libbase.lib(platform-win32.obj) : error LNK2001: unresolved external 
> symbol __imp_GetCurrentThreadId
> libcmt.lib(gs_support.obj) : error LNK2001: unresolved external symbol 
> __imp_GetCurrentThreadId
> libucrt.lib(per_thread_data.obj) : error LNK2001: unresolved external 
> symbol __imp_GetCurrentThreadId
> sampler.obj : error LNK2019: unresolved external symbol __imp_OpenThread 
> referenced in function "public: __cdecl v8::sampler::Sampler::Sampler(class 
> v8::Isolate *)" (??0Sampler@sampler@v8@@QEAA@PEAVIsolate@2@@Z)
> libucrt.lib(thread.obj) : error LNK2001: unresolved external symbol 
> __imp_CloseHandle
> libucrt.lib(close.obj) : error LNK2001: unresolved external symbol 
> __imp_CloseHandle
> libucrt.lib(open.obj) : error LNK2001: unresolved external symbol 
> __imp_CloseHandle
> libucrt.lib(initcon.obj) : error LNK2001: unresolved external symbol 
> __imp_CloseHandle
> [TRIMMED]
>
> Does anyone know what I'm doing wrong?
>
> 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.

Re: [v8-users] Is running a v8 instance built as a static library supported in the same process that loaded a different v8 instance in a DLL?

[Ben Noordhuis]

On Tue, Apr 17, 2018 at 12:27 AM, A.M.  wrote:
> I have an application that uses the v8 to run concurrent script jobs using
> multiple v8 isolates. There is a desire to move this application to Node.js,
> which puts the v8 used by the application in conflict with how Node.js uses
> its instance of the v8 (e.g. the v8 platform isn't exposed outside Node.js,
> etc).
>
> So, the question is, if I build the v8 as a static library and link it into
> the application, so it has its own globals, etc, will it still conflict with
> the instance of the v8 loaded by Node.js? I am thinking of any Windows
> global atom names, any names used within the v8 derived from the process ID
> (e.g. named mutexes, shared memory, etc) and so on.
>
> Application threads making calls into the static instance of the v8 will
> never cross into the Node.js v8 instance and vice versa, so if there is any
> thread local storage used allocated in any of the v8 calls, it should not
> cause any mix-up with TLS values. Likewise, any handles allocated in one v8
> instance will never make it into calls against another v8 instance. From the
> programmatic point of view both v8 instances are completely separated. I'm
> only worried about is any system resources that can be accessed via some OS
> mechanisms, like those mentioned above.
>
> Any thoughts on this would be greatly appreciated. Thanks.

Interesting question!

V8 doesn't use extra-process resources like named shm segments so I
don't see why it wouldn't work.  Not quite the same thing as
"officially supported" but there are no technical blockers that I can
think of.

Perhaps one caveat to keep in mind: V8 is pretty greedy when it comes
to reserving virtual memory.  It won't be a problem on 64 bits
platforms but on 32 bits you might run out of address space with two
V8 instances.

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