Re: [v8-users] mksnapshot fails on windows with is_official_build = true, is_component_build = true, use_custom_libcxx = false

[Jakob Gruber]

Interesting.. Sorry, I don't have any more suggestions either. Depending on
how much time you still have to spend on this, please consider either
filing a bug at crbug.com/v8/new to document your current findings, or
trying to build a minimal repro (without V8). I'd still like to understand
if this is a bug in V8 or in the MSVC stdlib.

On Wed, Aug 9, 2023 at 6:05 PM Jean-Claude Monnin 
wrote:

> Hi Jakob,
>
> Sorry, I should have looked at the code more carefully before sending my
> reply. The lambda capture-by-copy of the variadic template arguments being
> buggy would be one explanation, but it looks like it's something else.
>
> I tried following workaround:
> CodeRange* CodeRange::EnsureProcessWideCodeRange(
> v8::PageAllocator* page_allocator, size_t requested_size) {
>   base::CallOnce(_code_range_once, [&]() {
> InitProcessWideCodeRange(page_allocator, requested_size);
>   });
>   return process_wide_code_range_;
> }
> This uses the overload taking the `std::function` directly. It
> crashes in `CallOnceImpl` at call of `init_func()`.
> I also tried to call `CallOnceImpl` directly, same crash.
>
> It looks like the `std::function` is corrupted in `CallOnceImpl`. It works
> when supplying a static function with no arguments, but any lambda crashes.
> Using simpler test code, it seems that it's linked to pass a
> `std::function` across dll boundary. It works when calling an
> template/inline function, but calling a function exported by the dll
> doesn't work (see [1]).
> I can't see why passing a `std::function` to a dll call is problematic. I
> tested the same test code on another project that uses MSVC compiler and it
> works fine there. It's not impossible it's a clang issue. Unfortunately,
> this looks too complicated for me to look further into (I'm not familiar
> with assembler and such low level stuff).
>
> I tried this ugly workaround since I can pass static functions, which
> allows the compile to pass. d8.exe launches, but tests fail.
> v8::PageAllocator* g_page_allocator;
> size_t g_requested_size;
>
> static void InitProcessWideCodeRangeNoArgs() {
>   InitProcessWideCodeRange(g_page_allocator, g_requested_size);
> }
>
> // static
> CodeRange* CodeRange::EnsureProcessWideCodeRange(
> v8::PageAllocator* page_allocator, size_t requested_size) {
>   static base::Mutex mx;
>   base::MutexGuard guard();
>   g_page_allocator = page_allocator;
>   g_requested_size = requested_size;
>   base::CallOnce(_code_range_once, InitProcessWideCodeRangeNoArgs);
>   return process_wide_code_range_;
> }
>
> Regards,
> Jean-Claude
>
> ---
> [1] Test to reproduce the issue of passing a std::function across dll
> boundaries:
>
> src/base/once.h
> inline void Test1(std::function init_func) {
>   printf("Test1 before init_func\n");
>   init_func();
>   printf("Test1 after init_func\n");
> }
>
> V8_BASE_EXPORT void Test2(std::function init_func);
>
> src/base/once.cc
> void Test2(std::function init_func) {
>   printf("Test2 before init_func\n");
>   init_func();
>   printf("Test2 after init_func\n");
> }
>
> mksnapshot.cc
> void TestFunction() {
>   printf("  called TestFunction\n");
> }
>
> int main(int argc, char** argv) {
>   v8::base::Test1([]() {
> printf("  called CallOnceFake1 lambda\n");
>   });
>
>   v8::base::Test2(TestFunction);
>
>   v8::base::Test2([]() {
> printf("  called CallOnceFake2 lambda\n");
>   });
>
> The output is
>
> Test1 before init_func
>   called CallOnceFake1 lambda
> Test1 after init_func
> Test2 before init_func
>   called TestFunction
> Test2 after init_func
> Test2 before init_func
>
> The call to `Test2` with a lambda crashes
>
> On Wed, Aug 9, 2023, at 10:32 AM, Jakob Gruber wrote:
>
>
>
> On Wed, Aug 9, 2023 at 10:05 AM Jean-Claude Monnin <
> jc_mon...@emailplus.org> wrote:
>
>
> I've tried to figure out a bit more what is going on by adding prints
> along the call stack. It looks like it's the `base::CallOnce` in
> `code-range.cc` introduced in commit 26bc8bb4 that is the problem. Here the
> code with the added prints:
> V8_DECLARE_ONCE(init_code_range_once);
> void InitProcessWideCodeRange(v8::PageAllocator* page_allocator,
>   size_t requested_size) {
>   i::PrintF(stdout, "InitProcessWideCodeRange %u\n", requested_size);
>   CodeRange* code_range = new CodeRange();
>   if (!code_range->InitReservation(page_allocator, requested_size)) {
> V8::FatalProcessOutOfMemory(
> nullptr, "Failed to reserve virtual memory for CodeRange");
>   }
> 

Re: [v8-users] mksnapshot fails on windows with is_official_build = true, is_component_build = true, use_custom_libcxx = false

[Jakob Gruber]

On Wed, Aug 9, 2023 at 10:05 AM Jean-Claude Monnin 
wrote:

> I've tried to figure out a bit more what is going on by adding prints
> along the call stack. It looks like it's the `base::CallOnce` in
> `code-range.cc` introduced in commit 26bc8bb4 that is the problem. Here the
> code with the added prints:
> V8_DECLARE_ONCE(init_code_range_once);
> void InitProcessWideCodeRange(v8::PageAllocator* page_allocator,
>   size_t requested_size) {
>   i::PrintF(stdout, "InitProcessWideCodeRange %u\n", requested_size);
>   CodeRange* code_range = new CodeRange();
>   if (!code_range->InitReservation(page_allocator, requested_size)) {
> V8::FatalProcessOutOfMemory(
> nullptr, "Failed to reserve virtual memory for CodeRange");
>   }
>   process_wide_code_range_ = code_range;
> #ifdef V8_EXTERNAL_CODE_SPACE
> #ifdef V8_COMPRESS_POINTERS_IN_SHARED_CAGE
>   ExternalCodeCompressionScheme::InitBase(
>   ExternalCodeCompressionScheme::PrepareCageBaseAddress(
>   code_range->base()));
> #endif  // V8_COMPRESS_POINTERS_IN_SHARED_CAGE
> #endif  // V8_EXTERNAL_CODE_SPACE
> }
> }  // namespace
>
> // static
> CodeRange* CodeRange::EnsureProcessWideCodeRange(
> v8::PageAllocator* page_allocator, size_t requested_size) {
>   i::PrintF(stdout, "CodeRange::EnsureProcessWideCodeRange %u\n",
> requested_size);
>   base::CallOnce(_code_range_once, InitProcessWideCodeRange,
>  page_allocator, requested_size);
>   return process_wide_code_range_;
> }
>
> It outputs:
> CodeRange::EnsureProcessWideCodeRange 536870912
> InitProcessWideCodeRange 2034756544 <(203)%20475-6544>
>
> It looks like the `requested_size` isn't forwarded correctly in
> `base::CallOnce`.
> I'm not sure to understand the CallOnce implementation, but I wonder if
> calling `std::function` with `init_func(args...)` isn't undefined
> behavior. Not sure how to fix/work around.
>

Which part would be undefined behavior? From a quick glance, the CallOnce
implementation
<https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:v8/src/base/once.h;l=101;drc=a9163a67bbe920dfcfa6286bf0d172a1af377dba>
looks
reasonable to me. It sounds like something around the lambda
capture-by-copy is buggy (accessing the wrong stack slot?). Perhaps you can
verify with disassembly of InitProcessWideCodeRange, or step through and
find out what it's actually copying.


>
> On Wed, Aug 9, 2023, at 8:03 AM, Jakob Gruber wrote:
>
>
>
> On Tue, Aug 8, 2023 at 3:20 PM Jean-Claude Monnin 
> wrote:
>
>
> Hi Jakob,
>
> Thanks for your reply.
> It looks like using Microsoft's C++ library instead of libc++ is somewhat
> exotic for v8. Unfortunately there are cases where it's almost impossible
> to switch to libc++.
>
> Since I have a chance to get some feedback here of how to address this
> issue, I'm going to try to give you as much info as possible.
>
> `mksnapshot.exe` aborts at `VirtualMemoryCage::InitReservation` at
> following check:
>   CHECK(IsAligned(params.reservation_size, allocate_page_size));
>
> When adding following print on the line before
>   i::PrintF(stdout, "VirtualMemoryCage::InitReservation %u %u\n",
> params.reservation_size, allocate_page_size);
> it prints
>   VirtualMemoryCage::InitReservation 3356617664 65536
> It looks like the supplied `params.reservation_size` is not aligned.
>
>
> Thanks for the investigation, very helpful. I wonder where that
> reservation_size comes from. It doesn't look like any value we'd set in V8.
> Corrupted? Uninitialized?
>
> I'd expect it to be set by mksnapshot here
> <https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:v8/src/snapshot/mksnapshot.cc;l=282;drc=a9163a67bbe920dfcfa6286bf0d172a1af377dba>
>  and
> picked up by isolate initialization here
> <https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:v8/src/heap/heap.cc;l=5420;drc=a9163a67bbe920dfcfa6286bf0d172a1af377dba>.
> There it should either be some reasonable aligned value, or 0 and we'd fall
> back to kMaximalCodeRangeSize.
>
>
>
>
> Full call stack is included in screenshot below (sorry for the screenshot,
> I couldn't find a way to copy text from WinDbg)
>
> I'm happy to investigate further, but wanted to send this out in case
> there is anything specific that would be helpful.
>
> Jean-Claude
>
> On Tue, Aug 8, 2023, at 12:13 PM, Jakob Gruber wrote:
>
> Hi Jean-Claude,
>
> no, we don't have a lot of test coverage for `use_custom_libcxx=false`,
> this mode is only supported on a best-effort basis.
>
> For debugging: a backtrace and symbols would be useful. Does running
> `mksnapshot

Re: [v8-users] mksnapshot fails on windows with is_official_build = true, is_component_build = true, use_custom_libcxx = false

[Jakob Gruber]

Hi Jean-Claude,

no, we don't have a lot of test coverage for `use_custom_libcxx=false`,
this mode is only supported on a best-effort basis.

For debugging: a backtrace and symbols would be useful. Does running
`mksnapshot` in a debugger give more infos? Also, a bisect to find the
culprit change would be very helpful.

On Thu, Aug 3, 2023 at 6:54 PM Jean-Claude Monnin 
wrote:

> Hi,
>
> On windows, the v8 version 11.5 build fails when generating the snapshot
> with following error:
>
>
> C:/Users/jean-claude/Documents/src/google/depot_tools/bootstrap-2@3_8_10_chromium_26_bin/python3/bin/python3.exe
> ../../tools/run.py ./mksnapshot --turbo_instruction_scheduling
> --target_os=win --target_arch=x64 --embedded_src gen/embedded.S
> --embedded_variant Default --random-seed 314159265 --startup_blob
> snapshot_blob.bin --no-native-code-counters
> Return code is 2147483651 <(214)%20748-3651>
>
> These are the options used (args.gn):
> is_official_build = true
> target_cpu = "x64"
> is_component_build = true
> use_custom_libcxx = false
> chrome_pgo_phase = false
> treat_warnings_as_errors = false
> fatal_linker_warnings = false
> symbol_level = 0
>
> When using `is_debug=false` instead of `is_official_build = true` it
> builds fine, but it comes with performance regressions compared to older
> version 9.3 build with `is_official_build = true`.
>
> If using either `is_component_build = false` or `use_custom_libcxx =
> true`, it builds fine too, however it's not really an option as I need a
> dll build and I need to use Microsoft's C++ standard library because third
> party dependencies prevents us to use libc++.
>
> I also tried version 11.4 and 11.6 and they give the same error.
>
> Any hints in how to diagnose/fix that would be appreciated.
>
> Auxiliary question: Is any big project using `use_custom_libcxx = false`
> (eg. Microsoft's C++ standard library), or is this untested?
> Chrome/node/deno all use libc++?
>
> Best regards,
> Jean-Claude
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/984f3518-4b8e-4403-b794-923be66ccf08%40app.fastmail.com
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oO%2BEkjhuGaa9nXVWHd9Da3W4h0mr3ychCWu4J3gqRut8Q%40mail.gmail.com.

Re: [v8-users] Creating and returning a new v8::internal::Object within a runtime function

[Jakob Gruber]

Hi, something like this should work:

RUNTIME_FUNCTION(...) {
 ...
 return *isolate->factory()->NewNumber(number);
}

On Tue, Feb 14, 2023 at 8:19 PM Pradyumna Shome 
wrote:

> Hi all
>
> I'm trying to add a new runtime function to return the Data Pointer of an
> array as a v8::NumberObject, so I can operate upon memory addresses in
> other JavaScript commands. I'm having trouble constructing and returning an
> object of type v8::internal::Object, since it seems like every operation
> always returns a Local/Handle.
>
> I reached out to one of the developers (Jakob) separately, and they
> pointed me to the definition of v8::NumberObject::New
> .
> However, I'm unable to figure out the plumbing required to satisfy the
> compiler that what I'm returning from the runtime function is indeed a
> v8::internal::Object. I've shared what I've tried doing to troubleshoot,
> the error log (bolding the actual errors) and code snippet below.
>
> Best
> Pradyumna
>
> *What I've Tried*
>
>1. Constructing v8::StringObjects, v8::NumberObjects, and
>v8::internal::Numbers,by plumbing together APIs from
>
> https://v8docs.nodesource.com/node-0.8/da/d56/classv8_1_1_number_object.html
>and other sites.
>2. Reading the relevant pieces of https://v8.dev/docs/embed to
>understand what Local/Handle/Persistents are.
>3. Searched for call sites of the NumberObject/StringObject/Number
>APIs on the GitHub, Google, and You search engines to see if others have
>tried to do something similar. It turns out not a lot of people outside of
>the v8 developers are editing v8 (at least publicly).
>4. Read through numbers StackOverflow questions about construction
>v8::internal::objects, and manipulating Locals.
>5. Searching for related keywords on this forum.
>
>
> *Error Log (for one of the attempts)*
>
> # autoninja -C out/arm64.optdebug d8
> ninja: Entering directory `out/arm64.optdebug'
> [1/11] CXX obj/v8_base_without_compiler/runtime-test.o
> FAILED: obj/v8_base_without_compiler/runtime-test.o
> ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF
> obj/v8_base_without_compiler/runtime-test.o.d -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -DCR_XCODE_VERSION=1420
> -DCR_CLANG_REVISION=\"llvmorg-16-init-17653-g39da55e8-2\" -DCOMPONENT_BUILD
> -DCR_LIBCXX_REVISION=59bae40d835ae4eabaddbef781f5e3b778dd7907
> -D_LIBCPP_ENABLE_ASSERTIONS=1 -D_DEBUG -DDYNAMIC_ANNOTATIONS_ENABLED=1
> -DCPPGC_VERIFY_HEAP -DENABLE_DISASSEMBLER
> -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DOBJECT_PRINT -DVERIFY_HEAP
> -DV8_TRACE_MAPS -DV8_ENABLE_ALLOCATION_TIMEOUT -DV8_ENABLE_FORCE_SLOW_PATH
> -DV8_ENABLE_DOUBLE_CONST_STORE_CHECK -DV8_INTL_SUPPORT
> -DENABLE_HANDLE_ZAPPING -DV8_CODE_COMMENTS -DV8_ENABLE_DEBUG_CODE
> -DV8_ENABLE_HEAP_SNAPSHOT_VERIFY -DV8_SNAPSHOT_NATIVE_CODE_COUNTERS
> -DV8_USE_EXTERNAL_STARTUP_DATA -DV8_ATOMIC_OBJECT_FIELD_WRITES
> -DV8_ENABLE_LAZY_SOURCE_POSITIONS -DV8_SHARED_RO_HEAP
> -DV8_WIN64_UNWINDING_INFO -DV8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH
> -DV8_SHORT_BUILTIN_CALLS -DV8_EXTERNAL_CODE_SPACE -DV8_ENABLE_MAGLEV
> -DV8_ENABLE_TURBOFAN -DV8_ENABLE_SYSTEM_INSTRUMENTATION
> -DV8_ENABLE_WEBASSEMBLY -DV8_ALLOCATION_FOLDING
> -DV8_ALLOCATION_SITE_TRACKING -DV8_ADVANCED_BIGINT_ALGORITHMS
> -DV8_STATIC_ROOTS -DV8_USE_ZLIB -DV8_USE_LIBM_TRIG_FUNCTIONS
> -DV8_ENABLE_CHECKS -DV8_COMPRESS_POINTERS
> -DV8_COMPRESS_POINTERS_IN_SHARED_CAGE -DV8_31BIT_SMIS_ON_64BIT_ARCH
> -DV8_ENABLE_SANDBOX -DV8_DEPRECATION_WARNINGS
> -DV8_IMMINENT_DEPRECATION_WARNINGS -DCPPGC_CAGED_HEAP
> -DCPPGC_YOUNG_GENERATION -DCPPGC_POINTER_COMPRESSION
> -DCPPGC_SLIM_WRITE_BARRIER -DV8_TARGET_ARCH_ARM64 -DV8_HAVE_TARGET_OS
> -DV8_TARGET_OS_MACOS -DDEBUG -DV8_RUNTIME_CALL_STATS -DBUILDING_V8_SHARED
> -DUSING_V8_BASE_SHARED -DUSING_V8_PLATFORM_SHARED -DU_USING_ICU_NAMESPACE=0
> -DU_ENABLE_DYLOAD=0 -DUSE_CHROMIUM_ICU=1 -DU_ENABLE_TRACING=1
> -DU_ENABLE_RESOURCE_TRACING=0 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE
> -I../.. -Igen -I../../buildtools/third_party/libc++ -I../../include
> -Igen/include -I../../third_party/icu/source/common
> -I../../third_party/icu/source/i18n -I../../third_party/zlib -Wall -Werror
> -Wextra -Wimplicit-fallthrough -Wextra-semi -Wunreachable-code-aggressive
> -Wthread-safety -Wunguarded-availability -Wno-missing-field-initializers
> -Wno-unused-parameter -Wno-psabi -Wloop-analysis
> -Wno-unneeded-internal-declaration -Wenum-compare-conditional
> -Wno-ignored-pragma-optimize -Wno-deprecated-builtins
> -Wno-bitfield-constant-conversion -Wshadow -fno-delete-null-pointer-checks
> -fno-ident -fno-strict-aliasing -fstack-protector-strong
> -fcolor-diagnostics -fmerge-all-constants
> -fcrash-diagnostics-dir=../../tools/clang/crashreports -mllvm
> -instcombine-lower-dbg-declare=0 -ffp-contract=off
> -fcomplete-member-pointers -arch arm64 -fno-global-isel -mno-outline
> 

Re: [v8-users] Issues with preserve_most?

[Jakob Gruber]

+cleme...@chromium.org 

On Tue, Feb 7, 2023 at 3:55 PM ClearScript Developers <
clearscript...@gmail.com> wrote:

> Greetings!
>
> We've noticed that preserve_most was disabled
> 
> for Windows/arm64 on the 11.1 branch tip today.
>
> We'd actually been struggling with extreme instability in 11.1 release
> builds on Linux x64, so we tried disabling preserve_most for *all*
> platforms, and, surprisingly, that seems to have stabilized our Linux
> builds completely.
>
> So, it would appear that preserve_most issues go beyond Windows/arm64. In
> case it matters, we do use a relatively old toolchain to preserve
> compatibility with older distros.
>
> Anyone have any other experiences with preserve_most?
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/cb4f9835-165f-4e66-81e8-0de6164e0803n%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oPH-zuc18ebrWUa_6MhDqjnuwmsw_DhP5ez-hr7NYTY8A%40mail.gmail.com.

Re: [v8-users] iOS ARM64 only: undefined symbol: v8_Default_embedded_blob_code_

[Jakob Gruber]

Hey Benoit,

the v8_Default_embedded_blob_code_ symbol is created by the embedded file
writer

and
ends up in out/foo/gen/embedded.S in your build directory. I'd make sure
that file exists (or the .cc equivalent), has expected contents, and is
included in the build.

On Wed, Dec 7, 2022 at 10:08 AM Benoit Blanchon 
wrote:

> Hi,
>
> I successfully build PDFium with V8 on most platforms, but I'm having the
> following linker errors when target_os=ios and target_cpu=arm64:
>
> ld64.lld: error: undefined symbol: v8_Default_embedded_blob_code_
> >>> referenced by isolate.cc:0 (../v8/src/execution/isolate.cc:0)
> >>>   obj/v8/v8_base_without_compiler/isolate.o:(symbol
> v8::internal::Isolate::InitializeDefaultEmbeddedBlob()+0x104)
> >>> referenced by isolate.cc:0 (../v8/src/execution/isolate.cc:0)
> >>>   obj/v8/v8_base_without_compiler/isolate.o:(symbol
> v8::internal::Isolate::InitializeDefaultEmbeddedBlob()+0x100)
> >>> referenced by deoptimizer-cfi-builtins.cc:52
> (../v8/src/deoptimizer/deoptimizer-cfi-builtins.cc:52)
> >>>   obj/v8/v8_snapshot/deoptimizer-cfi-builtins.o:(symbol
> v8::internal::Deoptimizer::IsValidReturnAddress(unsigned long,
> v8::internal::Isolate*)+0x44)
> >>> referenced 1 more times
>
> ld64.lld: error: undefined symbol: v8_Default_embedded_blob_data_
> ...
> ld64.lld: error: undefined symbol: v8_Default_embedded_blob_data_size_
> ...
> ld64.lld: error: undefined symbol: v8_Default_embedded_blob_code_size_
> ...
> ld64.lld: error: undefined symbol: Builtins_RestartFrameTrampoline
> ...
> ld64.lld: error: undefined symbol:
> Builtins_BaselineOrInterpreterEnterAtNextBytecode
> ...
> ld64.lld: error: undefined symbol:
> Builtins_BaselineOrInterpreterEnterAtBytecode
> ...
> ld64.lld: error: undefined symbol: construct_stub_invoke_deopt_addr
> ...
> ld64.lld: error: undefined symbol: construct_stub_create_deopt_addr
> ...
> ld64.lld: error: undefined symbol: Builtins_ContinueToJavaScriptBuiltin
> ...
> ld64.lld: error: undefined symbol:
> Builtins_ContinueToJavaScriptBuiltinWithResult
> ...
> ld64.lld: error: undefined symbol: Builtins_ContinueToCodeStubBuiltin
> ...
> ld64.lld: error: undefined symbol:
> Builtins_ContinueToCodeStubBuiltinWithResult
> ...
> ld64.lld: error: undefined symbol: Builtins_InterpreterEnterAtNextBytecode
> ...
> ld64.lld: error: undefined symbol: Builtins_InterpreterEnterAtBytecode
>
> As far as I can tell, v8_Default_embedded_blob_data_ is defined
> in v8/src/builtins/arm64/builtins-arm64.cc, which seems to build fine (see
> log
> 
> ).
>
> I originally asked this question on the PDFium
>  list
> but was told to ask it here instead.
>
> Any idea how I could fix this?
>
> Best regards,
> Benoit
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/fedd3b80-41e9-4118-bccd-f0e0a6d6d569n%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oN-5W%2Bs-Gc-Ns6uvtm_1KAKH2UK5a7o6FobxegnyA5zzw%40mail.gmail.com.

Re: [v8-users] Re: Is it safe to reuse code cache generated before a context snapshot is serialized?

[Jakob Gruber]

I don't have any ideas right now; could you please file a bug with details
on how to compile and run the repro?

On Tue, Mar 15, 2022 at 9:12 PM jo...@igalia.com  wrote:

> Correction: in the snippet in the last reply, the comment `// This crashes
> with the stack trace below` should be `// This crashes with the stack trace
> above`.
> On Wednesday, March 16, 2022 at 4:10:33 AM UTC+8 jo...@igalia.com wrote:
>
>>
>> > Have you tried recreating the code cache as well in step 3?
>>
>> I gave it a try and the crash in debug build/error in release build
>> persist - I noticed that some code cache regenerated in step 3 have
>> payloads different from the one generated in step 1 (though both are
>> accepted when compilation is requested from the deserialized context).
>>
>> Another observation is that the crash happens in step 4, after compiling
>> the function with the code cache (no matter it's the regenerated  one or
>> not) and when I try to serialize a new code cache from the function:
>>
>> // It does not matter if GetCachedData() returns something created before
>> or after the snapshot is generated
>> ScriptCompiler::CachedData* cached_data = GetCachedData();
>> ScriptCompiler::Source script_source(source, origin, cached_data);
>> Local fun = ScriptCompiler::CompileFunctionInContext(context,
>> _source, ...).ToLocalChecked();
>> // This crashes with the stack trace below
>> ScriptCompiler::CreateCodeCacheForFunction(fun);
>>
>> If I do not try to refresh the code cache with a new one created from the
>> compiled function, and just continue execution as usual, it still crashes
>> at the same place during lazy compilation, but with the same memory address
>> as the one above (0x746c6975622f637d) being read as a instance type - so I
>> am wondering what's special about this value?
>>
>> * thread #1, queue = 'com.apple.main-thread', stop reason =
>> EXC_BAD_ACCESS (code=1, address=0x746c6975622f637d)
>>   * frame #0: 0x000100753390 node`short
>> std::__1::__cxx_atomic_load(__a=0x746c6975622f637d,
>> __order=memory_order_relaxed) at atomic:997:12
>> frame #1: 0x000100753340 node`std::__1::__atomic_base> false>::load(this=0x746c6975622f637d, __m=memory_order_relaxed) const
>> volatile at atomic:1603:17
>> frame #2: 0x0001007532fc node`short
>> std::__1::atomic_load_explicit(__o=0x746c6975622f637d,
>> __m=memory_order_relaxed) at atomic:1959:17
>> frame #3: 0x0001007532cc
>> node`v8::base::Relaxed_Load(ptr=0x746c6975622f637d) at atomicops.h:225:10
>> frame #4: 0x000100752f1c
>> node`v8::internal::Map::instance_type(this=0x00016fdfb058) const at
>> map-inl.h:344:7
>> frame #5: 0x0001007bd888
>> node`v8::internal::HeapObject::IsPrimitiveHeapObject(this=0x00016fdfb0c8,
>> cage_base=PtrComprCageBase @ 0x00016fdfb06f) const at
>> instance-type-inl.h:125:1
>> frame #6: 0x00010076a1fc
>> node`v8::internal::HeapObject::IsPrimitiveHeapObject(this=0x00016fdfb0c8)
>> const at instance-type-inl.h:125:1
>> frame #7: 0x00010216d870
>> node`v8::internal::IsPrimitiveHeapObject_NonInline(o=HeapObject @
>> 0x00016fdfb0c8) at primitive-heap-object-tq.cc:11:12
>> frame #8: 0x000100759654
>> node`v8::internal::TorqueGeneratedPrimitiveHeapObject> v8::internal::HeapObject>::TorqueGeneratedPrimitiveHeapObject(this=0x00016fdfb2e8,
>> ptr=58798249336529) at primitive-heap-object-tq-inl.inc:10:3
>> frame #9: 0x0001007595e4
>> node`v8::internal::PrimitiveHeapObject::PrimitiveHeapObject(this=0x00016fdfb2e8,
>> ptr=58798249336529) at primitive-heap-object-inl.h:20:1
>> frame #10: 0x000100759534
>> node`v8::internal::TorqueGeneratedName> v8::internal::PrimitiveHeapObject>::TorqueGeneratedName(this=0x00016fdfb2e8,
>> ptr=58798249336529) at name-tq-inl.inc:23:7
>> frame #11: 0x0001007594f4
>> node`v8::internal::Name::Name(this=0x00016fdfb2e8, ptr=58798249336529)
>> at name-inl.h:23:1
>> frame #12: 0x00010075a254
>> node`v8::internal::TorqueGeneratedString> v8::internal::Name>::TorqueGeneratedString(this=0x00016fdfb2e8,
>> ptr=58798249336529) at string-tq-inl.inc:183:7
>> frame #13: 0x00010075a214
>> node`v8::internal::String::String(this=0x00016fdfb2e8,
>> ptr=58798249336529) at string-inl.h:104:1
>> frame #14: 0x00010075a1d8
>> node`v8::internal::String::String(this=0x00016fdfb2e8,
>> ptr=58798249336529) at string-inl.h:104:1
>> frame #15: 0x0001007c90e4
>> node`v8::internal::TaggedField> 0>::load(cage_base=PtrComprCageBase @ 0x00016fdfb2e7, host=HeapObject @
>> 0x00016fdfb2d8, offset=104) at tagged-field-inl.h:69:10
>> frame #16: 0x000100c14f5c
>> node`v8::internal::TorqueGeneratedSymbol> v8::internal::Name>::SymbolPrint(this=0x,
>> os=0x00016fdfb390) at objects-printer.cc:16
>> frame #17: 0x000100c14e14
>> node`v8::internal::TorqueGeneratedHeapNumber> v8::internal::PrimitiveHeapObject>::HeapNumberPrint(this=0x18bb42ccd639,

Re: [v8-users] Re: Execution hang on v8::debug::EvaluateGlobal with kDisableBreaksAndThrowOnSideEffect

[Jakob Gruber]

On Tue, Feb 22, 2022 at 7:17 AM Jakob Gruber  wrote:

> Looks to me like a deadlock between
>
>   if (blocking_behavior == BlockingBehavior::kBlock) {
> base::MutexGuard lock_guard(_count_mutex_);
> while (ref_count_ > 0) ref_count_zero_.Wait(_count_mutex_);
>
>
> https://source.chromium.org/chromium/chromium/src/+/main:v8/src/compiler-dispatcher/optimizing-compile-dispatcher.cc;l=172;drc=a2d4701bea545269ad3f5fe6e111adb65c46b8da
>
> and
>
>   base::MutexGuard lock_guard(_->ref_count_mutex_);
>   if (--dispatcher_->ref_count_ == 0) {
>
>
> https://source.chromium.org/chromium/chromium/src/+/main:v8/src/compiler-dispatcher/optimizing-compile-dispatcher.cc;l=82;drc=a2d4701bea545269ad3f5fe6e111adb65c46b8da
>
> I'm puzzled how this should work, maybe I'm missing something. The
> ref_count_mutex_ is locked on both sides, so if we enter the while-loop
> waiting for it to hit zero, we can't actually decrement the ref count.
>

Indeed I missed the (obvious in hindsight)
`ref_count_zero_.Wait(_count_mutex_);` call, thanks tebbi@ for pointing
that out.


>
> On Tue, Feb 22, 2022 at 2:16 AM Igor Randjelovic 
> wrote:
>
>> Hello, I'm also from the NativeScript team...
>>
>> Another case that we found to hang the same way is whenever we handle the
>> `*Debugger.setBreakpointByUrl*` protocol message, in which case we see
>> the following stack:
>>
>> v8_inspector::(anonymous
>> namespace)::ActualScript::setBreakpoint(v8_inspector::String16 const&,
>> v8::debug::Location*, int*) const v8-debugger-script.cc:255
>> v8_inspector::V8DebuggerAgentImpl::setBreakpointImpl(v8_inspector::String16
>> const&, v8_inspector::String16 const&, v8_inspector::String16 const&, int,
>> int) v8-debugger-agent-impl.cc:953
>> v8_inspector::V8DebuggerAgentImpl::setBreakpointByUrl(int,
>> v8_crdtp::detail::ValueMaybe,
>> v8_crdtp::detail::ValueMaybe,
>> v8_crdtp::detail::ValueMaybe,
>> v8_crdtp::detail::ValueMaybe,
>> v8_crdtp::detail::ValueMaybe,
>> v8_inspector::String16*,
>> std::__Cr::unique_ptr> std::__Cr::default_delete >,
>> std::__Cr::allocator> std::__Cr::default_delete > >
>> >,
>> std::__Cr::default_delete> std::__Cr::default_delete >,
>> std::__Cr::allocator> std::__Cr::default_delete > > >
>> > >*) v8-debugger-agent-impl.cc:582
>> v8_inspector::protocol::Debugger::DomainDispatcherImpl::setBreakpointByUrl(v8_crdtp::Dispatchable
>> const&) Debugger.cpp:1333
>> v8_inspector::protocol::Debugger::DomainDispatcherImpl::Dispatch(v8_crdtp::span> char>)::$_29::operator()(v8_crdtp::Dispatchable const&) const
>> Debugger.cpp:519
>> decltype(std::__Cr::forward> char>)::$_29&>(fp)(std::__Cr::forward(fp0)))
>> std::__Cr::__invoke> char>)::$_29&, v8_crdtp::Dispatchable
>> const&>(v8_inspector::protocol::Debugger::DomainDispatcherImpl::Dispatch(v8_crdtp::span> char>)::$_29&, v8_crdtp::Dispatchable const&) type_traits:3694 void
>> std::__Cr::__invoke_void_return_wrapper> true>::__call> char>)::$_29&, v8_crdtp::Dispatchable
>> const&>(v8_inspector::protocol::Debugger::DomainDispatcherImpl::Dispatch(v8_crdtp::span> char>)::$_29&, v8_crdtp::Dispatchable const&) __functional_base:348
>> std::__Cr::__function::__default_alloc_func> char>)::$_29, void (v8_crdtp::Dispatchable
>> const&)>::operator()(v8_crdtp::Dispatchable const&) functional:1611 void
>> std::__Cr::__function::__policy_invoker> const&)>::__call_impl> char>)::$_29, void (v8_crdtp::Dispatchable const&)>
>> >(std::__Cr::__function::__policy_storage const*, v8_crdtp::Dispatchable
>> const&) functional:2092 void std::__Cr::__function::__policy_invoker> ()>::__call_impl> const&) const::$_0, void ()> >(std::__Cr::__function::__policy_storage
>> const*) 0xb91e6ee1 v8_crdtp::UberDispatcher::DispatchResult::Run()
>> 0xb91e516a
>> v8_inspector::V8InspectorSessionImpl::dispatchProtocolMessage(v8_inspector::StringView)
>> v8-inspector-session-impl.cc:451
>> tns::JsV8InspectorClient::doDispatchMessage(v8::Isolate*,
>> std::__Cr::basic_string,
>> std::__Cr::allocator > const&) JsV8InspectorClient.cpp:131
>> tns::JsV8InspectorClient::dispatchMessage(std::__Cr::basic_string> std::__Cr::char_traits, std::__Cr::allocator > const&)
>> JsV8InspectorClient.cpp:89
>> ::Java_com_tns_AndroidJsV8Inspector_dispatchMessage(JNIEnv *, jobject,
>> jstring) com_tns_AndroidJsV8Inspector.cpp:29
>> art_quick_generic_jni_trampoline 0xe400b2b3 art_quick_invoke_stu

Re: [v8-users] Re: Is it safe to reuse code cache generated before a context snapshot is serialized?

[Jakob Gruber]

> My understanding is that the serialized code and SFI and whatnot is part
of the context snapshot

To clarify, the code cache is separate from the isolate/context snapshot;
and neither contain serialized Code (Bytecode is possible though).

It does sound like snapshots are getting confused somewhere, resulting in
broken object graphs. Not sure what exactly is going wrong though. Have you
tried recreating the code cache as well in step 3?

On Mon, Feb 21, 2022 at 8:48 PM jo...@igalia.com  wrote:

> I'd like to add that so far we've found two scripts that can trigger this
> with the Node.js user land snapshot prototype (the prototype works
> otherwise fine with applications as complicated as the TypeScript
> compiler), which are placed in
> https://github.com/joyeecheung/node/tree/snapshot-mem-bug as
> test/fixtures/snapshot/mem-bug.js and test/fixtures/snapshot/mem-bug2.js.
> They both seem pretty random to me. I'll paste them below for the record:
>
> ```
> 'use strict';
>
> var re = /./;
> re.exec = function () {
> var result = [];
> result.groups = { a: '7' };
> return result;
> };
> ''.replace(re, '$') !== '7';
> ```
>
> ```
> 'use strict';
>
> var chars = ('a'+'#').split('');
> var entity = {};
> for (var c of chars) {
> entity[c] = true;
> }
> ```
>
>
> On Tuesday, February 22, 2022 at 3:39:48 AM UTC+8 jo...@igalia.com wrote:
>
>> Hi,
>>
>> I am running into a bug and I am not sure if it's caused by inappropriate
>> usage of the SnapshotCreator API or a bug in V8. This was an issue
>> discovered when working on the user land snapshot prototype in Node.js (
>> https://github.com/nodejs/node/pull/38905), the upstream issue is
>> https://github.com/nodejs/node/issues/40832. This prototype does a few
>> things:
>>
>> 1. It generates code cache for a list of scripts.
>> 2. It then run a subset of scripts mentioned in 1 to initialize a context
>> and uses the code cache generated in 1 to compile them during the process.
>> Then it snapshots the context with the v8::SnapshotCreator (this is the
>> bootstrap snapshot that Node.js releases currently ship with).
>> 3. A Node.js binary is built with the code cache and the initial snapshot
>> mentioned in 1 & 2. It uses the snapshot built in step 2 to bootstrap
>> itself, then executes a script specified by the user, and generates another
>> context snapshot, then serializes it into another blob.
>> 4. It initializes the context again with the snapshot blob generated in
>> step 3 (which replaces the snapshot blob generated in 2), but when it needs
>> to load any scripts not executed in 2 or 3, it still uses the code cache
>> generated in step 1.
>>
>> My understanding is that the serialized code and SFI and whatnot is part
>> of the context snapshot, and as long as the sanity check passes, the code
>> cache generated before the snapshot should be the same as the one in the
>> snapshot if FunctionCodeHandling::kKeep is used. However the prototype runs
>> into several memory bugs during deserialization of the user land snapshot -
>> in release mode a script not included in the snapshot but compiled with the
>> old code cache (that is, it is not executed after the final snapshot is
>> loaded) throws an NonCallable error with a value strangely turning into
>> undefined. In debug mode a relaxed load from a map crashes with
>> EXC_BAD_ACCESS during compilation. So I suspect that this bug has something
>> to do with GC or the concurrent compiler, but it is difficult to reproduce
>> with only V8 - perhaps it needs a particular graph to trigger this bug and
>> the prototype happens to generate such graphs more reliably.
>>
>> Steps to reproduce:
>>
>> 1. Check out https://github.com/joyeecheung/node/tree/snapshot-mem-bug,
>> build it with the instructions in
>> https://github.com/nodejs/node/blob/rundefined/BUILDING.md (I do `cd
>> /path/to/node && ./configure --ninja && ninja -C out/Release`). This is a
>> prototype that allows user to specify a user script to snapshot with
>> --snapshot-main, and generates a context snapshot containing a Node.js
>> application using v8::SnapshotCreator. It can load the snapshot with
>> another flag --snapshot-blob.
>> 2. Run `out/Release/node --snapshot-main
>> test/fixtures/snapshot/mem-bug.js && out/Release/node --snapshot-blob
>> snapshot.blob test/fixtures/empty.js`, which throws the following error
>> (some logging shows that the PromiseResolve function turned into undefined):
>>
>> ```
>> node:internal/modules/esm/module_job:32
>> const resolvedPromise = PromiseResolve();
>> ^
>>
>> TypeError: PromiseResolve is not a function
>> at node:internal/modules/esm/module_job:32:25
>> at NativeModule.compileForInternalLoader
>> (node:internal/bootstrap/loaders:312:7)
>> at nativeModuleRequire (node:internal/bootstrap/loaders:341:14)
>> at node:internal/modules/esm/module_map:3:19
>> at NativeModule.compileForInternalLoader
>> (node:internal/bootstrap/loaders:312:7)
>> at 

Re: [v8-users] Re: Execution hang on v8::debug::EvaluateGlobal with kDisableBreaksAndThrowOnSideEffect

[Jakob Gruber]

Looks to me like a deadlock between

  if (blocking_behavior == BlockingBehavior::kBlock) {
base::MutexGuard lock_guard(_count_mutex_);
while (ref_count_ > 0) ref_count_zero_.Wait(_count_mutex_);

https://source.chromium.org/chromium/chromium/src/+/main:v8/src/compiler-dispatcher/optimizing-compile-dispatcher.cc;l=172;drc=a2d4701bea545269ad3f5fe6e111adb65c46b8da

and

  base::MutexGuard lock_guard(_->ref_count_mutex_);
  if (--dispatcher_->ref_count_ == 0) {

https://source.chromium.org/chromium/chromium/src/+/main:v8/src/compiler-dispatcher/optimizing-compile-dispatcher.cc;l=82;drc=a2d4701bea545269ad3f5fe6e111adb65c46b8da

I'm puzzled how this should work, maybe I'm missing something. The
ref_count_mutex_ is locked on both sides, so if we enter the while-loop
waiting for it to hit zero, we can't actually decrement the ref count.

On Tue, Feb 22, 2022 at 2:16 AM Igor Randjelovic  wrote:

> Hello, I'm also from the NativeScript team...
>
> Another case that we found to hang the same way is whenever we handle the `
> *Debugger.setBreakpointByUrl*` protocol message, in which case we see the
> following stack:
>
> v8_inspector::(anonymous
> namespace)::ActualScript::setBreakpoint(v8_inspector::String16 const&,
> v8::debug::Location*, int*) const v8-debugger-script.cc:255
> v8_inspector::V8DebuggerAgentImpl::setBreakpointImpl(v8_inspector::String16
> const&, v8_inspector::String16 const&, v8_inspector::String16 const&, int,
> int) v8-debugger-agent-impl.cc:953
> v8_inspector::V8DebuggerAgentImpl::setBreakpointByUrl(int,
> v8_crdtp::detail::ValueMaybe,
> v8_crdtp::detail::ValueMaybe,
> v8_crdtp::detail::ValueMaybe,
> v8_crdtp::detail::ValueMaybe,
> v8_crdtp::detail::ValueMaybe,
> v8_inspector::String16*,
> std::__Cr::unique_ptr std::__Cr::default_delete >,
> std::__Cr::allocator std::__Cr::default_delete > >
> >,
> std::__Cr::default_delete std::__Cr::default_delete >,
> std::__Cr::allocator std::__Cr::default_delete > > >
> > >*) v8-debugger-agent-impl.cc:582
> v8_inspector::protocol::Debugger::DomainDispatcherImpl::setBreakpointByUrl(v8_crdtp::Dispatchable
> const&) Debugger.cpp:1333
> v8_inspector::protocol::Debugger::DomainDispatcherImpl::Dispatch(v8_crdtp::span char>)::$_29::operator()(v8_crdtp::Dispatchable const&) const
> Debugger.cpp:519
> decltype(std::__Cr::forward char>)::$_29&>(fp)(std::__Cr::forward(fp0)))
> std::__Cr::__invoke char>)::$_29&, v8_crdtp::Dispatchable
> const&>(v8_inspector::protocol::Debugger::DomainDispatcherImpl::Dispatch(v8_crdtp::span char>)::$_29&, v8_crdtp::Dispatchable const&) type_traits:3694 void
> std::__Cr::__invoke_void_return_wrapper true>::__call char>)::$_29&, v8_crdtp::Dispatchable
> const&>(v8_inspector::protocol::Debugger::DomainDispatcherImpl::Dispatch(v8_crdtp::span char>)::$_29&, v8_crdtp::Dispatchable const&) __functional_base:348
> std::__Cr::__function::__default_alloc_func char>)::$_29, void (v8_crdtp::Dispatchable
> const&)>::operator()(v8_crdtp::Dispatchable const&) functional:1611 void
> std::__Cr::__function::__policy_invoker const&)>::__call_impl char>)::$_29, void (v8_crdtp::Dispatchable const&)>
> >(std::__Cr::__function::__policy_storage const*, v8_crdtp::Dispatchable
> const&) functional:2092 void std::__Cr::__function::__policy_invoker ()>::__call_impl const&) const::$_0, void ()> >(std::__Cr::__function::__policy_storage
> const*) 0xb91e6ee1 v8_crdtp::UberDispatcher::DispatchResult::Run()
> 0xb91e516a
> v8_inspector::V8InspectorSessionImpl::dispatchProtocolMessage(v8_inspector::StringView)
> v8-inspector-session-impl.cc:451
> tns::JsV8InspectorClient::doDispatchMessage(v8::Isolate*,
> std::__Cr::basic_string,
> std::__Cr::allocator > const&) JsV8InspectorClient.cpp:131
> tns::JsV8InspectorClient::dispatchMessage(std::__Cr::basic_string std::__Cr::char_traits, std::__Cr::allocator > const&)
> JsV8InspectorClient.cpp:89
> ::Java_com_tns_AndroidJsV8Inspector_dispatchMessage(JNIEnv *, jobject,
> jstring) com_tns_AndroidJsV8Inspector.cpp:29
> art_quick_generic_jni_trampoline 0xe400b2b3 art_quick_invoke_stub
> 0xe4004aa3 art::ArtMethod::Invoke(art::Thread*, unsigned int*,
> unsigned int, art::JValue*, char const*) 0xe4099502
> art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*,
> art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)
> 0xe424f882 bool art::interpreter::DoCall false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction
> const*, unsigned short, art::JValue*) 0xe4243bbf void
> art::interpreter::ExecuteSwitchImplCpp false>(art::interpreter::SwitchImplContext*) 0xe4017fcf
> ExecuteSwitchImplAsm 0xe400bf63
> art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&,
> art::ShadowFrame&, art::JValue, bool, bool) (.llvm.10914192770458939989)
> 0xe4238e02
> art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*,
> art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)
> 

Re: [v8-users] Preliminary RFC: Stabilizing the V8 script compiler cached data format

[Jakob Gruber]

On Mon, Jul 26, 2021 at 11:19 AM Leszek Swirski 
wrote:

> On Fri, Jul 23, 2021 at 1:18 AM Vitali Lovich  wrote:
>
>> What's the best way to measure script parse time vs lazy function
>> compilation time? It's been a few months since I last looked at this so my
>> memory is a bit hazy on whether it was instantiating
>> v8::ScriptCompiler::Source, v8::ScriptCompiler::CompileUnboundScript, or
>> the combined time of both (although I suspect both count as script parse
>> time?). I do recall that on my laptop, using the code cache basically
>> halved the time on larger scripts of what I was measuring & I suspect I
>> would have looked at the overall time to instantiate the isolate with a
>> script (it was a no-op on smaller scripts, so I suspect we're talking about
>> script parse time).
>>
>
> The best way is to run with --runtime-call-stats, this will give you
> detailed scoped timers for almost everything we do, including compilation.
> Script deserialisation is certainly faster than script compilation, so I'm
> not surprised it has a big impact when the two are compared against each
> other, I'm more curious how it compares to overall worklet runtime.
>
>
>> FWIW, if It's helpful, when I profiled a stress test of isolate
>> construction on my machine with a release build, I saw V8 spending a lot of
>> time deserializing the snapshot (seemingly once for the isolate & then
>> again for the context).
>>
>
> Yeah, the isolate snapshot is the ~immutable context-independent one
> (think of things like the "undefined" value) which is deserialized once per
> isolate, and the context snapshot is things that are mutable (think of
> things like the "Math" object) that have to be fresh per new context. Note
> that these snapshots use the same mechanism as the code cache snapshot, but
> are otherwise entirely distinct.
>
>
>> Breakdown of the flamegraph:
>> * ~22% of total runtime to run NewContextFromSnapshot. Within that ~5% of
>> total runtime was spent just decompressing the snapshot & the rest was
>> deserializing it (17%). I thought there was only 1 snapshot. Couldn't the
>> decompression happen once in V8System instead?
>>
>
> It's possible that the decompression could be once per isolate, although
> there is the memory impact to consider.
>

Snapshot compression can be disabled during the build, see
https://source.chromium.org/chromium/chromium/src/+/main:v8/BUILD.gn;l=288;drc=67960ba110803b053a772eff7aeac6c5d2f23143
.


>
>
>> * 9% of total runtime spent decompressing the snapshot for the isolate
>> (in other words 14% of total runtime was spent decompressing the snapshot).
>>
>> In our use-case we construct a lot of isolates in the same process. I'm
>> curious if there's opportunities to extend V8 to utilize COW to reduce the
>> memory & CPU impact of deserializing the snapshot multiple times. Is my
>> guess correct that deserialization is actually doing non-trivial things
>> like relocating objects or do you think there's a 0-copy approach that can
>> be taken with serializing/deserializing the snapshot so that it's prebuilt
>> in the right format (perhaps even without any compression)?
>>
>
> There's definitely relocations happening during deserialisation; for the
> isolate, we've wanted to share the "read-only space" which contains
> immutable immortal objects (like "undefined"), but under pointer
> compression this has technical issues because of limited guarantees when
> using mmap (IIRC). I imagine COW for the context snapshot would have
> similar issues, combined with the COW getting immediately defeated as soon
> as the GC runs (because it has to mutate the data to set mark bits). It's a
> direction worth exploring, but hasn't been enough of a priority for us.
>
> Another thing we're considering looking into is deserializing the context
> snapshot lazily, so that unused functions/classes never get deserialized in
> the first place. Again, not something we've had time to prioritise, but
> something we're much more likely to work on at some point in the future,
> since it becomes more web relevant every time new functionality is
> introduced.
>
> I fully understand. I'm definitely interested in the snapshot format since
>> presumably anything that helps the web here will also help us. Is there a
>> paper I can reference to read up more on the proposal? I've seen a few in
>> the wild from the broader JS community but nothing about V8's plans here. I
>> have no idea if that will help our workload but it's certainly something
>> we're open to exploring.
>>
>
> You're probably thinking of BinaryAST, which is unrelated to this. We
> haven't talked much about web snapshots yet, because it's still very
> preliminary, very prototypy, and we don't want to make any promises or
> guarantees around it even ever materialising. +Marja Hölttä
>  is leading this effort, she'll know the current
> state.
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You 

Re: [v8-users] Building for iOS: requested alignment must be 536870912 bytes or smaller

[Jakob Gruber]

Updating instructions here https://github.com/v8/v8.dev/pull/549 (feel free
to create pull requests yourself if you have addtl improvements).

On Tue, May 4, 2021 at 5:17 PM Richard  wrote:

> Turning off pointer compression was the solution...
>
> On Tuesday, May 4, 2021 at 11:17:21 AM UTC-4 Richard wrote:
>
>> It looks like that fixed it. There are some general build errors now, but
>> if they pose a problem, I'll post again.
>>
>> Thanks!
>>
>> On Tuesday, May 4, 2021 at 3:40:38 AM UTC-4 Clemens Backes wrote:
>>
>>> Alternatively, remove that use of V8_ASSUME_ALIGNED. It's just a hint
>>> for the compiler, it's not needed for correctness.
>>>
>>> On Tue, May 4, 2021 at 7:30 AM Jakob Gruber  wrote:
>>>
>>>> Try turning off pointer compression:
>>>> https://source.chromium.org/chromium/chromium/src/+/main:v8/BUILD.gn;l=121;drc=f98f496f9e5e9faea58e1de737d9d46e2248b337
>>>>
>>>> Let us know if it works, we should update the iOS instructions page if
>>>> so.
>>>>
>>>> On Mon, May 3, 2021 at 2:20 PM Richard  wrote:
>>>>
>>>>> I'm getting this error when building for iOS:
>>>>>
>>>>> In file included from
>>>>> ../../v8/v8/src/builtins/builtins-async-iterator-gen.cc:11:
>>>>> In file included from ../../v8/v8/src/execution/frames-inl.h:13:
>>>>> In file included from ../../v8/v8/src/objects/objects-inl.h:21:
>>>>> In file included from ../../v8/v8/src/heap/heap-write-barrier-inl.h:15:
>>>>> In file included from
>>>>> ../../v8/v8/src/objects/compressed-slots-inl.h:10:
>>>>> ../../v8/v8/src/common/ptr-compr-inl.h:25:35: error: requested
>>>>> alignment must be 536870912 bytes or smaller; maximum alignment assumed
>>>>> [-Werror,-Wbuiltin-assume-aligned-alignment]
>>>>>   ret = reinterpret_cast(V8_ASSUME_ALIGNED(
>>>>>   ^~
>>>>> ../../v8/v8/include/v8config.h:388:3: note: expanded from macro
>>>>> 'V8_ASSUME_ALIGNED'
>>>>>   __builtin_assume_aligned((ptr), (alignment))
>>>>>   ^   ~~~
>>>>> 1 error generated.
>>>>>
>>>>> My build settings are:
>>>>>
>>>>> enable_ios_bitcode = true
>>>>> ios_deployment_target = 10
>>>>> is_component_build = false
>>>>> is_debug = false
>>>>> target_cpu = "arm64"
>>>>> target_os = "ios"
>>>>> use_custom_libcxx = false
>>>>> use_xcode_clang = true
>>>>> v8_enable_i18n_support = false
>>>>> v8_monolithic = true
>>>>> v8_use_external_startup_data = false
>>>>>
>>>>> Any ideas how to fix this?
>>>>>
>>>>> --
>>>>> --
>>>>> 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.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/v8-users/07a36602-b2f1-4771-a061-5ef359d3a16dn%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/v8-users/07a36602-b2f1-4771-a061-5ef359d3a16dn%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> --
>>>> --
>>>> 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.
>>>>
>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/v8-users/CAH3p7oPOEE_whBAnriaf_eXi5JnjkR%3DYZ1AxWSFPn9wd5QJpiQ%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/v8-users/CAH3p7oPOEE_whBAnriaf_eXi5JnjkR%3DYZ1AxWSFPn9wd5QJpiQ%40mail.gmail.com?utm_medium=email_source=footer>
>>>

Re: [v8-users] Building for iOS: requested alignment must be 536870912 bytes or smaller

[Jakob Gruber]

Try turning off pointer compression:
https://source.chromium.org/chromium/chromium/src/+/main:v8/BUILD.gn;l=121;drc=f98f496f9e5e9faea58e1de737d9d46e2248b337

Let us know if it works, we should update the iOS instructions page if so.

On Mon, May 3, 2021 at 2:20 PM Richard  wrote:

> I'm getting this error when building for iOS:
>
> In file included from
> ../../v8/v8/src/builtins/builtins-async-iterator-gen.cc:11:
> In file included from ../../v8/v8/src/execution/frames-inl.h:13:
> In file included from ../../v8/v8/src/objects/objects-inl.h:21:
> In file included from ../../v8/v8/src/heap/heap-write-barrier-inl.h:15:
> In file included from ../../v8/v8/src/objects/compressed-slots-inl.h:10:
> ../../v8/v8/src/common/ptr-compr-inl.h:25:35: error: requested alignment
> must be 536870912 bytes or smaller; maximum alignment assumed
> [-Werror,-Wbuiltin-assume-aligned-alignment]
>   ret = reinterpret_cast(V8_ASSUME_ALIGNED(
>   ^~
> ../../v8/v8/include/v8config.h:388:3: note: expanded from macro
> 'V8_ASSUME_ALIGNED'
>   __builtin_assume_aligned((ptr), (alignment))
>   ^   ~~~
> 1 error generated.
>
> My build settings are:
>
> enable_ios_bitcode = true
> ios_deployment_target = 10
> is_component_build = false
> is_debug = false
> target_cpu = "arm64"
> target_os = "ios"
> use_custom_libcxx = false
> use_xcode_clang = true
> v8_enable_i18n_support = false
> v8_monolithic = true
> v8_use_external_startup_data = false
>
> Any ideas how to fix this?
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/07a36602-b2f1-4771-a061-5ef359d3a16dn%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oPOEE_whBAnriaf_eXi5JnjkR%3DYZ1AxWSFPn9wd5QJpiQ%40mail.gmail.com.

Re: [v8-users] Snapshot limitations

[Jakob Gruber]

I think crbug.com/v8/10500 will answer some of your questions. Short
version: no, currently you can't snapshot a running isolate with arbitrary
state. Also take a look at the d8 --stress-snapshot

flag,
which takes a snapshot after executing arbitrary JS but without
guaranteeing that the resulting deserialized heap state is still executable
(in many cases it won't be). Re. modules support, see crbug.com/v8/10855.

On Mon, Mar 8, 2021 at 8:35 PM Roey Berman  wrote:

> Hi,
>
> I'm trying to create a persistent v8 runtime where I can at any point take
> a snapshot of a running isolate.
> I'm wondering what the limitations of SnapshotCreator are.
> I have only seen it being used for creating startup snapshots.
> Is it possible to call SnapshotCreator.CreateBlob() multiple times on the
> same instance?
> I got a segfault when I tried that but I couldn't see anything the implies
> that it shouldn't be safe in the docs.
> Also, is it possible to load modules during snapshot creation?
>
> Thanks,
> - Roey
>
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/afb077fd-4f2a-4cd0-8288-627343307eden%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oPOTf40rEO4XZ5-ybCQwZTtEShBBwEP-x_OyBuLuzTw7Q%40mail.gmail.com.

Re: [v8-users] Reduce V8 size by eliminating unused features

[Jakob Gruber]

+Clemens Backes  I know we'd discussed a flag to make
wasm optional in the past, was there any progress?

On Sat, Jan 30, 2021 at 11:48 AM Ben Noordhuis  wrote:

> On Fri, Jan 29, 2021 at 9:17 PM Tekman  wrote:
> >
> > Hi,
> >
> > Do you have any tips for reducing the size of an embedded V8 by removing
> unnecessary functionality (such as wasm or worker support)? Size on disk
> comes to mind since I presume runtime cost is already pay-for-play.
> >
> > We're looking for a basic ES6 runtime environment that is compact and
> efficient (with JIT support), without any of the bells & whistles.
> >
> > Thank you!
>
> Take a look at BUILD.gn, V8 has a veritable zoo of build options. The
> two quickest wins are probably v8_enable_lite_mode=true and
> v8_enable_i18n_support=false (drops the dependency on ICU, which is
> _big_.)
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/CAHQurc-1pU92-OYo6cYQjxGwi0mr7FS2c2bWkiy5g8Un2v1SKw%40mail.gmail.com
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oP2VYDXu7tvb%2Bzf1Afk2zFs%2B1bor8Jx8usgcYvRUbnONw%40mail.gmail.com.

Re: [v8-users] Re: run_torgue fails when compiling under windows (use_custom_libcxx=false)

[Jakob Gruber]

+Nico Hartmann 

On Tue, Jan 26, 2021 at 1:27 PM Thomas Liebmann <
thorsten.baess...@siemens.com> wrote:

> Update:
> I tried to run torque in the debugger. It fails with:
> Unhandled exception at 0x7FFA38D9F7A0 (ntdll.dll) in torque.exe:
> RangeChecks instrumentation code detected an out of range array access.
>
> Thomas Liebmann schrieb am Freitag, 22. Januar 2021 um 11:31:15 UTC+1:
>
>> Hi,
>>
>> I'm trying to compile 8.8.278.14 under Windows and MSVC 2017 using the
>> following flags:
>>
>> gn gen out/x64-win.release --args="is_debug=false target_cpu=\"x64\"
>> v8_target_cpu=\"x64\" use_goma=false is_clang=true v8_static_library=false
>> is_component_build=true use_custom_libcxx=false
>> v8_untrusted_code_mitigations=true"
>>
>> Unfortunatly it fails on step run_torgue
>> [31/2673] ACTION //:run_torque(//build/toolchain/win:win_clang_x64)
>> ...
>> Return code is C409
>>
>> Any ideas are appreciated.
>>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/2319fc26-0e87-4e0f-aa4e-f243638cc912n%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oMXg%2Bx%2BvVBE4-_wfV79PEoxaz9R2uoRwT7MxTUYE%3DYR%3Dw%40mail.gmail.com.

Re: [v8-users] iOS 14.2 now supports JIT

[Jakob Gruber]

Interesting.. Enabling jitting in V8 should be as easy as removing the
--jitless flag (see e.g. here
).
I'm curious if the app store guidelines will also change to allow codegen
for dynamic content (= web pages).

On Sat, Nov 7, 2020 at 6:58 AM Patric Lemo  wrote:

>
> https://twitter.com/altstoreio/status/1324473755062599680
>
> Is it possible for v8 to support JIT on iOS in the near future?
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/167a1e0a-350a-4081-acb7-87291a715df6n%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oOfzc1WKakdy%3DL9tiq9bNzFTFXp_YK6L9Z3GEQe7_GT4A%40mail.gmail.com.

Re: [v8-users] Getting unstable builds of V8 under Mac OS

[Jakob Gruber]

I verified locally that d8 built with

is_component_build = false
is_debug = true
v8_optimized_debug = true
use_custom_libcxx = false

on a macbook works fine. The build completes, and d8 runs some trivial
examples without issues. Same with v8_cppgc_shared_unittests which you
mentioned in your latest email.

I would try starting over with a clean checkout, building d8 with the gn
flags above. If something still doesn't work, please file a bug at
crbug.com/v8/new with exact reproduction steps.

On Mon, Oct 12, 2020 at 7:47 PM Cameron Caturria <
surviving.deceptive.wo...@gmail.com> wrote:

> Hi,
> v8_optimized_debug = false gives the following:
>
> ninja: Entering directory `out.gn/x64.release'
> [1/1] Regenerating ninja files
> [1184/2682] LINK ./v8_cppgc_shared_unittests
> FAILED: v8_cppgc_shared_unittests
> TOOL_VERSION=1602521620 ../../build/toolchain/mac/linker_driver.py
>
> -Wcrl,strippath,/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip
> ../../third_party/llvm-build/Release+Asserts/bin/clang++ -B
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/
>  -Wl,-fatal_warnings -stdlib=libc++ -arch x86_64 -Werror -isysroot
>
> ../../../../../Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
> -mmacosx-version-min=10.10.0 -Wl,-ObjC -Wl,-rpath,@loader_path/.
> -Wl,-rpath,@loader_path/../../.. -o "./v8_cppgc_shared_unittests"
> -Wl,-filelist,"./v8_cppgc_shared_unittests.rsp"
> ./libv8_cppgc_shared_for_testing.dylib ./libv8_libbase.dylib
> ld: warning: direct access in function
> 'testing::internal::SuiteApiResolver namespace)::FailureTest>::GetSetUpCaseOrSuite(char const*, int)' from
> file 'obj/third_party/googletest/gtest/gtest.o' to global weak symbol
> 'testing::Test::SetUpTestSuite()' from file
> 'obj/test/unittests/v8_cppgc_shared_unittests_sources/worklist-unittest.o'
> means the weak symbol cannot be overridden at runtime. This was likely
> caused by different translation units being compiled with different
> visibility settings.
> ld: warning: direct access in function
> 'testing::internal::SuiteApiResolver namespace)::FailureTest>::GetSetUpCaseOrSuite(char const*, int)' from
> file 'obj/third_party/googletest/gtest/gtest.o' to global weak symbol
> 'testing::Test::SetUpTestCase()' from file
> 'obj/test/unittests/v8_cppgc_shared_unittests_sources/worklist-unittest.o'
> means the weak symbol cannot be overridden at runtime. This was likely
> caused by different translation units being compiled with different
> visibility settings.
> ld: warning: direct access in function
> 'testing::internal::SuiteApiResolver namespace)::FailureTest>::GetTearDownCaseOrSuite(char const*, int)'
> from file 'obj/third_party/googletest/gtest/gtest.o' to global weak
> symbol 'testing::Test::TearDownTestSuite()' from file
> 'obj/test/unittests/v8_cppgc_shared_unittests_sources/worklist-unittest.o'
> means the weak symbol cannot be overridden at runtime. This was likely
> caused by different translation units being compiled with different
> visibility settings.
> ld: warning: direct access in function
> 'testing::internal::SuiteApiResolver namespace)::FailureTest>::GetTearDownCaseOrSuite(char const*, int)'
> from file 'obj/third_party/googletest/gtest/gtest.o' to global weak
> symbol 'testing::Test::TearDownTestCase()' from file
> 'obj/test/unittests/v8_cppgc_shared_unittests_sources/worklist-unittest.o'
> means the weak symbol cannot be overridden at runtime. This was likely
> caused by different translation units being compiled with different
> visibility settings.
> ld: fatal warning(s) induced error (-fatal_warnings)
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> Traceback (most recent call last):
>   File "../../build/toolchain/mac/linker_driver.py", line 287, in 
> Main(sys.argv)
>   File "../../build/toolchain/mac/linker_driver.py", line 97, in Main
> subprocess.check_call(compiler_driver_args, env=env)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
> line 190, in check_call
> raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command
> '['../../third_party/llvm-build/Release+Asserts/bin/clang++', '-B',
>
> '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/',
> '-Wl,-fatal_warnings', '-stdlib=libc++', '-arch', 'x86_64', '-Werror',
> '-isysroot',
> '../../../../../Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk',
> '-mmacosx-version-min=10.10.0', '-Wl,-ObjC',
> '-Wl,-rpath,@loader_path/.', '-Wl,-rpath,@loader_path/../../..', '-o',
> './v8_cppgc_shared_unittests',
> '-Wl,-filelist,./v8_cppgc_shared_unittests.rsp',
> './libv8_cppgc_shared_for_testing.dylib', './libv8_libbase.dylib']'
> returned non-zero exit status 1
> [1189/2682] ACTION
> 

Re: [v8-users] Getting unstable builds of V8 under Mac OS

[Jakob Gruber]

On Mon, Oct 12, 2020 at 2:38 AM Cameron Caturria <
surviving.deceptive.wo...@gmail.com> wrote:

> Hi,
> I have been trying for some time to build a working V8 static library
> under Mac OS with limited success. I can get it to build, but the
> result is unstable.
> I have successfully setup depot-tools, added it to my $PATH, fetched
> V8 and checked out the desired version (I selected version 8.1.307,
> since this is the version that ships with the latest stable Node.js).
> If I use the one step build process after gclient sync:
> Tools/dev/gm.py x64.release
> The result is a build that doesn’t work at all (v8::V8::Initialize()
> never returns, program hangs).
> If I add use_custom_libcxx to build arguments as suggested by this
> related Stack Overflow question:
>
> https://stackoverflow.com/questions/62250913/cross-compiling-v8-for-arm-hello-world-hangs-during-initialize
> I get a somewhat usable build with some stability issues.
> Specifically, it will crash inside of all error object constructors
> (v8::Exception::RangeError, v8::Exception::TypeError etc).
>

We'll need more information. Please compile a debug build

is_debug = true
v8_optimized_debug = false

and paste the output. A backtrace would also help. What are the target/host
platforms? Please also use the latest version / current git master.

The v8_shell sample application that builds alongside V8 works as it
> should, but if I build it myself it crashes after evaluating every
> line.
> I am new to V8, and the documentation is anything but beginner
> friendly. In addition to the embedding guide, I am mostly relying on
> the API reference made available by nodesource.com.
> I am using the following build args:
>
> is_component_build = false
> is_debug = false
> target_cpu = "x64"
> use_goma = false
> goma_dir = "None"
> v8_enable_backtrace = true
> v8_enable_disassembler = true
> v8_enable_object_print = true
> v8_enable_verify_heap = true
> use_custom_libcxx=false
> I am using the default Clang which ships with Xcode:
>
> Apple clang version 11.0.0 (clang-1100.0.33.12)
> Target: x86_64-apple-darwin19.6.0
> Thread model: posix
> InstalledDir:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> I am using the following compiler and linker flags to build the
> shell.cc example:
> g++ -O3 -std=c++0x ./shell.cc -I/usr/local/include/v8 -lwee8
> -lv8_libbase -lv8_libplatform -pthreads -o v8_shell
>
> A nudge in the right direction would be greatly appreciated.
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/CAKAqCuw0ypWySMq6N4snKj9b6Zvygp_eVQ4T2EZ3BQyRp1oy8A%40mail.gmail.com
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oNrDQWD7LsKVmD4Tbdj7-J5ZTSEMD3xEpuOZz9rz%2Bygxw%40mail.gmail.com.

Re: [v8-users] Re: Failed to cross compile v8 for iOS: error: unknown directive .type PushAllRegistersAndIterateStack

[Jakob Gruber]

+Michael Lippautz 

On Fri, May 8, 2020 at 3:25 PM 许超前  wrote:

> I compiled latest v8 on macOS catalina(10.15.4), with the following gn
> args:
>
> enable_ios_bitcode = true
>
> ios_deployment_target = 10
>
> is_component_build = false
>
> is_debug = false
>
> target_cpu = "arm64"  # "x64" for a simulator build.
>
> target_os = "ios"
>
> use_custom_libcxx = false # Use Xcode's libcxx.
>
> use_xcode_clang = true
>
> v8_enable_i18n_support = false# Produces a smaller binary.
>
> v8_monolithic = true  # Enable the v8_monolith target.
>
> v8_use_external_startup_data = false  # The snaphot is included in the
> binary.
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/e25b0852-e834-4d39-b937-40dad8c8a713%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oO6cNphY1LjAXLYspin%2BmpCEzG9PdsEVR9JjsG0itEcqw%40mail.gmail.com.

Re: [v8-users] Disabling V8 snapshots for ARM cross-compiles

[Jakob Gruber]

Filed https://crbug.com/v8/10414 to track this.

On Thu, Apr 9, 2020 at 2:16 PM Thomas Preston <
thomas.pres...@codethink.co.uk> wrote:

> Yes, that would save some time building. Please let me know if there's any
> update on this. Thank you
>
> On Wednesday, 8 April 2020 15:52:08 UTC+1, Jakob Gruber wrote:
>>
>> It sounds like we could improve support for this case by providing a gn
>> argument for prebuilt `snapshot_blob.bin` and `embedded.S` artifacts. If
>> provided, we could skip building mksnapshot entirely. Would that help?
>>
>> On Wed, Jan 29, 2020 at 10:44 AM Thomas Preston <
>> thomas...@codethink.co.uk> wrote:
>>
>>> On Wednesday, 29 January 2020 09:37:48 UTC, Thomas Preston wrote:
>>>
>>>> We ended up solving this by letting the run_mksnapshot_default target
>>>> finish, then overwriting snapshot_blob.bin and embedded.S with the
>>>> pre-built 32-bit versions. The build actually errors when trying to build
>>>> another target, which uses embedded.S.
>>>>
>>>
>>> This is the error when we don't replace the snapshot_blob.bin and
>>> embedded.S with 32-bit versions:
>>>
>>> .quad V8FooBar
>>>   ^ unsupported relocation on symbol
>>>
>>>
>>>
>>> --
>>> --
>>> 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-u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/v8-users/a8c43168-2ff4-4a6a-bead-850a6e43fa30%40googlegroups.com
>>> <https://groups.google.com/d/msgid/v8-users/a8c43168-2ff4-4a6a-bead-850a6e43fa30%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/3955444e-46df-4639-9a3d-8c3405259fb6%40googlegroups.com
> <https://groups.google.com/d/msgid/v8-users/3955444e-46df-4639-9a3d-8c3405259fb6%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oMrt0o4OV2niO19jqUA2jGWgRiA%3D%3D2T5%2BnvQanG3ROYEQ%40mail.gmail.com.

Re: [v8-users] Disabling V8 snapshots for ARM cross-compiles

[Jakob Gruber]

It sounds like we could improve support for this case by providing a gn
argument for prebuilt `snapshot_blob.bin` and `embedded.S` artifacts. If
provided, we could skip building mksnapshot entirely. Would that help?

On Wed, Jan 29, 2020 at 10:44 AM Thomas Preston <
thomas.pres...@codethink.co.uk> wrote:

> On Wednesday, 29 January 2020 09:37:48 UTC, Thomas Preston wrote:
>
>> We ended up solving this by letting the run_mksnapshot_default target
>> finish, then overwriting snapshot_blob.bin and embedded.S with the
>> pre-built 32-bit versions. The build actually errors when trying to build
>> another target, which uses embedded.S.
>>
>
> This is the error when we don't replace the snapshot_blob.bin and
> embedded.S with 32-bit versions:
>
> .quad V8FooBar
>   ^ unsupported relocation on symbol
>
>
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/a8c43168-2ff4-4a6a-bead-850a6e43fa30%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oP%3D1Zyk6%3D7cBswO-t5mwSwP1dhQX_qxhweV3QMga5P02A%40mail.gmail.com.

Re: [v8-users] Disabling V8 snapshots for ARM cross-compiles

[Jakob Gruber]

On Tue, Jan 7, 2020 at 3:13 PM Thomas Preston <
thomas.pres...@codethink.co.uk> wrote:

> On Tuesday, 7 January 2020 09:14:36 UTC, Jakob Gruber wrote:
>>
>> On Mon, Jan 6, 2020 at 6:30 PM Thomas Preston 
>> wrote:
>>
>>> Hi,
>>> We have noticed that the latest version of Chromium makes the v8
>>> snapshot build mandatory.
>>> We were turning this off for building under Buildroot (for linux,
>>> targetting 32-bit ARM), because Buildroot has no concept of multilib, and
>>> host packages can't be installed with 32-bit memory architectures.
>>> Is there any way to continue to disable v8 snapshot building? If not,
>>> where can we find out more about building ARM 32-bit V8 snapshots on x64
>>> hosts?
>>>
>>
>> Unfortunately there's currently no easy way to do this. A 64-bit
>> mksnapshot binary (currently) cannot create 32-bit snapshots.
>>
>> Your best bet is to build snapshot_blob.bin and embedded.S elsewhere
>> (e.g. on the host system or in a VM). The final build could then use these
>> generated files and skip the mksnapshot step. Would that be an option for
>> you?
>>
>> See also the Known Issues section here
>> <https://docs.google.com/document/d/1Irnq29OIGWMkcsXmazECZii95eIGQoyrYsmriHvpk-M/edit#heading=h.k26jzph28qte>
>> .
>>
>>
> That's useful, thanks. It looks like checking-in pre-built 32-bit
> artifacts is the way to go.
>
> Is it possible to just run mksnapshot? Maybe we can just tell ninja to
> build `obj/v8/v8_snapshot/embedded.o`
>

Yes that's certainly possible. Try the run_mksnapshot target
<https://cs.chromium.org/chromium/src/v8/BUILD.gn?l=1253=73b25eab2d914aa2be8eb2d223eee7c1b93b45a0>.
Make sure to use the same git hash and build config though between the
mksnapshot run and the final V8 build!


> Full-Chromium requires a 64-bit build environment
> https://chromium.googlesource.com/chromium/src/+/master/docs/linux/build_instructions.md
>
>

> Alternatively, are there any pre-built artifacts we can just download?
> This would be ideal, as we wouldn't have to check in large files to
> Buildroot.
>

No, sorry. I do like the idea, but we don't have anything like that right
now.


> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/d6503022-b79e-47bc-8fad-4207b6a69b21%40googlegroups.com
> <https://groups.google.com/d/msgid/v8-users/d6503022-b79e-47bc-8fad-4207b6a69b21%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oPbxn-YfxqMza_qKOuiQ2BWf90ubEiA35WN0LYY-69z%2Bg%40mail.gmail.com.

Re: [v8-users] Disabling V8 snapshots for ARM cross-compiles

[Jakob Gruber]

On Mon, Jan 6, 2020 at 6:30 PM Thomas Preston <
thomas.pres...@codethink.co.uk> wrote:

> Hi,
> We have noticed that the latest version of Chromium makes the v8 snapshot
> build mandatory.
> We were turning this off for building under Buildroot (for linux,
> targetting 32-bit ARM), because Buildroot has no concept of multilib, and
> host packages can't be installed with 32-bit memory architectures.
> Is there any way to continue to disable v8 snapshot building? If not,
> where can we find out more about building ARM 32-bit V8 snapshots on x64
> hosts?
>

Unfortunately there's currently no easy way to do this. A 64-bit mksnapshot
binary (currently) cannot create 32-bit snapshots.

Your best bet is to build snapshot_blob.bin and embedded.S elsewhere (e.g.
on the host system or in a VM). The final build could then use these
generated files and skip the mksnapshot step. Would that be an option for
you?

See also the Known Issues section here

.

Note there's no technical reason why mksnapshot cannot support 64-to-32
cross-builds, so it may become possible in the future. There are no
concrete plans at the moment though (you could file bug at crbug.com/v8/new
).


>
> Many thanks,
> Thomas
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/c805e785-68d0-44bd-b207-e2848a9c3c76%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oOVB%3DWrMVC2h%2BQ_uSSOxphgPc8bXeph1%2B9-b9ZXegKWWw%40mail.gmail.com.

Re: [v8-users] CpuProfiler not collecting data in jitless mode (iOS)

[Jakob Gruber]

+Peter Marshall 

On Wed, Nov 6, 2019 at 8:58 AM Darin Dimitrov 
wrote:

> I am trying to collect function execution data using the CpuProfiler class.
>
> I ran the following test (taken from here
> https://github.com/v8/v8/blob/master/test/cctest/test-cpu-profiler.cc#L677
> ):
>
> const char* src =
> "function loop(timeout) {\n"
> "  this.mmm = 0;\n"
> "  var start = Date.now();\n"
> "  do {\n"
> "var n = 1000;\n"
> "while(n > 1) {\n"
> "  n--;\n"
> "  this.mmm += n * n * n;\n"
> "}\n"
> "  } while (Date.now() - start < timeout);\n"
> "}\n"
> "function delay() { loop(10); }\n"
> "function bar() { delay(); }\n"
> "function baz() { delay(); }\n"
> "function foo() {\n"
> "  delay();\n"
> "  bar();\n"
> "  delay();\n"
> "  baz();\n"
> "}\n"
> "function start(duration) {\n"
> "  var start = Date.now();\n"
> "  do {\n"
> "foo();\n"
> "  } while (Date.now() - start < duration);\n"
> "}\n";
>
> Script::Compile(context, v8::String::NewFromUtf8(isolate, src).
> ToLocalChecked()).ToLocalChecked()->Run(context).ToLocalChecked();
> Local startFunc = context->Global()->Get(context, v8::String
> ::NewFromUtf8(isolate, "start").ToLocalChecked()).ToLocalChecked().As Function>();
>
> Local title = v8::String::NewFromUtf8(isolate, "my_trace").
> ToLocalChecked();
> CpuProfiler* profiler = CpuProfiler::New(isolate);
> profiler->StartProfiling(title, false);
>
> Local result;
> Local args[] = { Number::New(isolate, 200) };
> assert(startFunc->Call(context, context->Global(), 1, args).ToLocal(&
> result));
>
> const CpuProfile* profile = profiler->StopProfiling(title);
> const CpuProfileNode* root = profile->GetTopDownRoot();
> int count = root->GetChildrenCount();
> for (int i = 0; i < count; ++i) {
> const CpuProfileNode* child = root->GetChild(i);
> v8::String::Utf8Value str(isolate, child->GetFunctionName());
> const char* funcName = *str;
> printf("%s\n", funcName);
> }
>
>
>
> The root CpuProfileNode contains only a single child element called
> "(program)".
>
> If I execute the same code on Android, I correctly get the following child
> functions: "(program)", "start" and "(garbage collector)".
>
> Do you have any idea what might be wrong with the CpuProfiler class in v8
> in jitless mode? Is CpuProfiler the correct class to use to collect
> function execution times or is there some newer method?
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/798f9464-88a1-464f-8fb8-6aa223ce5e57%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oP%3DOKA8UCZgxFrLehh3ULbWGF-FU0%2BdnXop2%3DuW574k%2Bw%40mail.gmail.com.

Re: [v8-users] Is "monolithic" build of v8 for static linking incompatible with "v8_use_snapshot=true"?

[Jakob Gruber]

Set

v8_use_external_startup_data = false

to compile the snapshot into the binary. I don't think there's any reason
external snapshots would not work in monolithic builds. The assert is
likely guarding the fact that the build produces exactly one single file.

On Tue, Oct 29, 2019 at 7:07 AM Ben Ernst  wrote:

> Following some frustrations with dynamic linking to V8, I thought I'd try
> the static linked build.
>
> My platform is VS2017, Windows 10.
>
> My arguments to "gn" (via "v8gen") are as follows:
>
> treat_warnings_as_errors=false
> is_component_build=false
> v8_enable_i18n_support=false
> v8_use_snapshot=true
> v8_monolithic=true
>
> When I try to build V8, I get this error:
>
>  [exec]
> **
>  [exec] ** Visual Studio 2017 Developer Command Prompt v15.9.11
>  [exec] ** Copyright (c) 2017 Microsoft Corporation
>  [exec]
> **
>  [exec] [vcvarsall.bat] Environment initialized for: 'x64'
>  [exec] ninja: Entering directory `out.gn/x64.release'
>  [exec] [1/1] Regenerating ninja files
>  [exec] FAILED: build.ninja
>  [exec] ../../buildtools/win/gn.exe --root=../.. -q --check gen .
>  [exec] ERROR at //BUILD.gn:3779:3: Assertion failed.
>  [exec]   assert(!v8_use_external_startup_data)
>  [exec]   ^-
>  [exec] ninja: error: rebuilding 'build.ninja': subcommand failed
>
> Is "v8_monolith" incompatible with "v8_use_snapshot"? How does one get
> around this 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/1ff68a3b-07c3-43f6-aaed-56a8001a7fe8%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oPKpFHd7xBtmuoS6Pj_jhcXSVTBTCPMO-qnDhAsiE0trQ%40mail.gmail.com.

Re: [v8-users] V8 Regex Optimizations

[Jakob Gruber]

If you embed V8 yourself, the runtime flags --regexp-tier-up and
--regexp-tier-up-ticks
<https://cs.chromium.org/chromium/src/v8/src/flags/flag-definitions.h?l=1267=be638514c9876e80c222068059b205d64091c78d>
control
tier-up behavior.

Do you have an example of a particularly slow regexp pattern and subject
string?

On Thu, Oct 24, 2019 at 10:14 PM Joel Scarfone 
wrote:

> Let's say I have a Script that uses somewhere in the realm 100 regex's in
> different functions. I want the first call to each of those functions to be
> fast, so I move the constructor to the global object to pre-compile the
> regex's. From the v8 docs, "In its default configuration, V8 compiles
> regular expressions to native code upon the first execution", so I force
> this pre-complication with something like `for(var rule of regexRules) {
> "".match(regex) } `. Doing this, I notice a significant improvement in the
> execution on first call back into the context to execute a function that
> uses these regex's.
>
> Is there a way to change this default configuration?
>
> Joel
>
> On Thursday, 24 October 2019 01:12:54 UTC-4, Jakob Gruber wrote:
>>
>>
>>
>> On Wed, Oct 23, 2019 at 5:12 PM Joel Scarfone 
>> wrote:
>>
>>> Hi!
>>>
>>> I'm looking for details on how v8's regular expression optimizations
>>> work under the covers, and if there might be something to improve the
>>> performance of a given regular expressions first execution. From what it
>>> looks like trying some things out, v8 does most of it's optimizations after
>>> a call that uses the RegExp and not when the constructor is called (eg.
>>> through `new RegExp()`).
>>>
>>
>> I'm not aware of much documentation on this topic. A recent blog post (
>> https://v8.dev/blog/regexp-tier-up) discusses the recent addition of
>> tiering and describes performance work on the interpreter. But for details
>> you'll have to dig through the source code.
>>
>> As you say, a regexp is compiled lazily at the first exec call. With
>> tiering, we first compile to bytecode, then later recompile to native code.
>> There are many intricacies involved, e.g. we cache compilation artifacts
>> keyed on {pattern,flags}, and constructing a regexp instance is expected to
>> be cheaper from a literal (/abc/) than when using the constructor (new
>> RegExp("abc", "")).
>>
>>
>>>
>>> I am Wondering what some options are in this area to move around the
>>> cost of compiling/running the regular expression.
>>>
>>
>> I think I'd need more details on what you want to achieve to give a
>> meaningful answer.
>>
>>
>>>
>>> Thanks in advance!
>>>
>>> Joel
>>>
>>> --
>>> --
>>> 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-u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/v8-users/05a13931-5a1d-4b21-8616-ffd3010dd03a%40googlegroups.com
>>> <https://groups.google.com/d/msgid/v8-users/05a13931-5a1d-4b21-8616-ffd3010dd03a%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/ecb02276-8ccd-4f1f-b3bd-6aba79799985%40googlegroups.com
> <https://groups.google.com/d/msgid/v8-users/ecb02276-8ccd-4f1f-b3bd-6aba79799985%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oMO5UNfKy%2BBdujiq5YHY4X95evgfu9x-z3M3ZYdVEoP8g%40mail.gmail.com.

Re: [v8-users] V8 Regex Optimizations

[Jakob Gruber]

On Wed, Oct 23, 2019 at 5:12 PM Joel Scarfone 
wrote:

> Hi!
>
> I'm looking for details on how v8's regular expression optimizations work
> under the covers, and if there might be something to improve the
> performance of a given regular expressions first execution. From what it
> looks like trying some things out, v8 does most of it's optimizations after
> a call that uses the RegExp and not when the constructor is called (eg.
> through `new RegExp()`).
>

I'm not aware of much documentation on this topic. A recent blog post (
https://v8.dev/blog/regexp-tier-up) discusses the recent addition of
tiering and describes performance work on the interpreter. But for details
you'll have to dig through the source code.

As you say, a regexp is compiled lazily at the first exec call. With
tiering, we first compile to bytecode, then later recompile to native code.
There are many intricacies involved, e.g. we cache compilation artifacts
keyed on {pattern,flags}, and constructing a regexp instance is expected to
be cheaper from a literal (/abc/) than when using the constructor (new
RegExp("abc", "")).


>
> I am Wondering what some options are in this area to move around the cost
> of compiling/running the regular expression.
>

I think I'd need more details on what you want to achieve to give a
meaningful answer.


>
> Thanks in advance!
>
> Joel
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/05a13931-5a1d-4b21-8616-ffd3010dd03a%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oMfNbHjpW8w%3DhO4QUNNE%2BsH_j8UVupNF86%2BKkaZYxz2JQ%40mail.gmail.com.

Re: [v8-users] Create heap snapshot for x86 from 64 bit process

[Jakob Gruber]

On Thu, Oct 24, 2019 at 6:31 AM zhao shengyue  wrote:

> Does V8 have any plan on it,  by enabling a 64-bit version of mksnapshot
> that can produce 32-bit arm code?
>

We don't currently have plans to implement 64-to-32-bit cross compiles.
Please feel free to file a bug at crbug.com/v8/new though, I don't think we
have one tracking this yet.


>
> i found Flutter/Dart has same problem, and fix it already,  see E
> <https://github.com/dart-lang/sdk/issues/36839>nable gen_snapshot to be
> compiled for X64 host and ARM target (SIMARM_X64 build)
> <https://github.com/dart-lang/sdk/issues/36839> .
>
>
> 在 2019年8月26日星期一 UTC+8下午4:51:08，Jakob Gruber写道：
>>
>> On Mon, Aug 26, 2019 at 10:41 AM Darin Dimitrov 
>> wrote:
>>
>>> Is it possible to create heap snapshot using the "mksnapshot" tool for
>>> x86 or armeabi-v7a CPU architectures from a 64 bit process. If yes, what
>>> are the steps to build such "mksnapshot" executable?
>>>
>>
>> Unfortunately, no. Cross-bitness builds are not supported at the moment.
>> Would building inside a Linux VM be an option?
>>
>>
>>> Mac OS Catalina drops support for 32 bit executables and we would like
>>> to still be able to produce heap snapshots for x86 or armeabi-v7a
>>> architectures on this host OS.
>>>
>>> --
>>> --
>>> 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-u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/v8-users/aeb27954-4333-4a50-8f0f-273dbee63923%40googlegroups.com
>>> <https://groups.google.com/d/msgid/v8-users/aeb27954-4333-4a50-8f0f-273dbee63923%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/aa2fb210-2404-468f-87a8-31c8ed143a74%40googlegroups.com
> <https://groups.google.com/d/msgid/v8-users/aa2fb210-2404-468f-87a8-31c8ed143a74%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oPs9h8FKBYJpPa8jmepq_8-%2BP%3D16iFxvKFfH6Kwj1e-PQ%40mail.gmail.com.

Re: [v8-users] Overriding platform specific logging feature

[Jakob Gruber]

Is the override specific to iOS or to a particular application? If the
former, why not upstream it in V8?

On Wed, Oct 9, 2019 at 2:17 PM Darin Dimitrov 
wrote:

> I am embedding V8 in an iOS application and I would like to override the
> "OS::Print" method:
> https://chromium.googlesource.com/v8/v8.git/+/3.7.12.26/src/platform-posix.cc#217
>
> This method already handles the Android case by redirecting the output to
> logcat:
>
> void OS::VPrint(const char* format, va_list args) {
> #if defined(ANDROID) && !defined(V8_ANDROID_LOG_STDOUT)
>   __android_log_vprint(ANDROID_LOG_INFO, LOG_TAG, format, args);
> #else
>   vprintf(format, args);
> #endif
> }
>
> What would be the best way to override this method for my platform without
> modifying the V8 source code (I have compiled V8 as a static library that I
> am linking against in my iOS application)?
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/acfff90d-6acd-47fa-984b-ebe2def46853%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oOZ3B6XhY-5jFmJjP1k-kZ_%3DPvL__St1ep6cjoJup6JZQ%40mail.gmail.com.

Re: [v8-users] Calling js functions in jitless (iOS)

[Jakob Gruber]

It'd be interesting to find out what more. We should not attempt to jump
into runtime-allocated executable code in jitless mode. If you have a
repro, please open a bug and I will take a look.

On Thu, Sep 12, 2019 at 5:45 PM Darin Dimitrov 
wrote:

> Found the root cause.
>
> I was setting a named interceptor on an instance template with both the
> propertyGetter and propertySetter being null:
>
> NamedPropertyHandlerConfiguration config(propertyGetter, propertySetter);
>
> instanceTemplate->SetHandler(config);
>
>
> I am not sure how how this affects V8 and what is the relation to
> 738d870db64a97db243e0d5856f92cc45e1c69fd
> 
>  but
> once I added null checks, everything works perfectly.
>
>
> On Thursday, September 12, 2019 at 6:29:57 PM UTC+3, Darin Dimitrov wrote:
>
>> I have pretty much narrowed it down and will send a repro once I remove
>> all the noise from my project
>>
>> On Thursday, September 12, 2019 at 5:45:19 PM UTC+3, Jakob Kummerow wrote:
>>>
>>> CC author of that commit.
>>>
>>> Darin, do you have a full repro you can share? That would be useful for
>>> debugging.
>>>
>>>
>>> On Thu, Sep 12, 2019 at 4:36 PM Darin Dimitrov 
>>> wrote:
>>>
 I am embedding v8 in my iOS application and calling some js function:

 Local callback = ...

 std::vector> v8Args = ...

 Local result;

 TryCatch tc(isolate);

 callback->Call(context, thiz, (*int*)v8Args.size(), v8Args.data()).
 ToLocal());


 This code works pretty fine but starting from this commit
 https://chromium.googlesource.com/v8/v8.git/+/738d870db64a97db243e0d5856f92cc45e1c69fd
  my code started failing consistently with the following error:


 * thread #1, queue = 'com.apple.main-thread', stop reason =
 EXC_BAD_ACCESS (code=EXC_I386_GPFLT)

   * frame #0: 0x0001031f1fe0
 MyProj`v8::internal::PropertyCallbackArguments::CallNamedSetter(this=0x7ffeedc03aa0,
 interceptor=, name=,
 value=Handle @ 0x7ffeedc039e8) at
 api-arguments-inl.h:231:3 [opt]

 frame #1: 0x00010315e11d
 MyProj`v8::internal::__RT_impl_Runtime_StorePropertyWithInterceptor(args=Arguments
 @ 0x7ffeedc03af0, isolate=0x00011faf8000) at ic.cc:2760:37 [opt]

 frame #2: 0x000103cd6f00
 MyProj`Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit + 
 64

 frame #3: 0x000103ef0ccf
 MyProj`Builtins_StaNamedPropertyHandler + 1679

 frame #4: 0x000103a0be52
 MyProj`Builtins_InterpreterEntryTrampoline + 946

 frame #5: 0x0001039fe57a MyProj`Builtins_JSEntryTrampoline + 90

 frame #6: 0x0001039fe57a MyProj`Builtins_JSEntryTrampoline + 90

 frame #7: 0x0001039fe358 MyProj`Builtins_JSEntry + 120

 frame #8: 0x000103064512 MyProj`v8::internal::(anonymous
 namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous
 namespace)::InvokeParams const&) [inlined]
 v8::internal::GeneratedCode>>> unsigned long, unsigned long, long, unsigned
 long**>::Call(this=, args=, args=,
 args=, args=, args=,
 args=) at simulator.h:138:12 [opt]

 frame #9: 0x000103064509 MyProj`v8::internal::(anonymous
 namespace)::Invoke(isolate=0x00011faf8000,
 params=)::InvokeParams const&) at execution.cc:266 [opt]

 frame #10: 0x000103063e27
 MyProj`v8::internal::Execution::Call(isolate=0x00011faf8000,
 callable=, receiver=, argc=1,
 argv=0x61a8cee0) at execution.cc:358:10 [opt]

 frame #11: 0x000102d3a80d
 MyProj`v8::Function::Call(this=0x7fdeee81b840, context=,
 recv=, argc=1, argv=0x61a8cee0) at api.cc:4840:7 [opt]



 And this is the crashing code:
 https://chromium.googlesource.com/v8/v8.git/+/738d870db64a97db243e0d5856f92cc45e1c69fd/src/api/api-arguments-inl.h#231


 The crash is observed after multiple calls to this method and after
 some GC iterations.

 --

>>> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/b8576c7a-8eb8-4ac3-8810-6180728303c5%40googlegroups.com
> 
> .
>

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

Re: [v8-users] Calling function from shared library in V8 7.7.299.11

[Jakob Gruber]

Could this be another libcxx mismatch issue and 7.7 just exposes it
incidentally?

On Thu, Sep 12, 2019 at 2:54 PM Darin Dimitrov 
wrote:

> I am cross compiling V8 for android and I have created a shared library
> containing a simple function which adds some property to a provided object:
>
> extern "C" void MyFunc(Isolate* isolate, Local& obj) {
> Local context = isolate->GetCurrentContext();
> obj->Set(context, v8::String::NewFromUtf8(isolate, 
> "someProp").ToLocalChecked(), Number::New(isolate, 500));
> }
>
>
> My goal  purpose is to call this function from my android application in 
> which I have embedded V8:
>
>
> typedef void (*MyCallback)(Isolate* isolate, Local& obj);
>
>
> void* handle = 
> dlopen("/data/data/com.tns.testapplication/files/app/modules/libCalc-x86_64.so",
>  RTLD_LAZY);
>
> MyCallback func = reinterpret_cast(dlsym(handle, "MyFunc"));
> Local exportsObj = Object::New(isolate);
> func(isolate, exportsObj);
>
>
> This successfully invokes "MyFunc" from the shared library and sets the 
> "someProp" property on the passed object.
>
>
> Starting from V8 *7.7.299.11* calling obj->Set() inside the library crashes 
> with SIGSEGV and without any stacktrace.
>
>
> I have noticed that if I set the property before calling the function then it 
> works:
>
>
> exportsObj->Set(context, v8::String::NewFromUtf8(isolate, 
> "someProp").ToLocalChecked(), v8::Null(isolate));
> func(isolate, exportsObj);
>
>
> Any idea what might have changed between the official V8 7.6 and 7.7 releases 
> that might explain this behaviour or any tips that would allow me to debug 
> this further?
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/48a71b41-b96e-41ec-9450-fa36d6f1bb45%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oN1B3HPc%2BVicC0-YB5R%2BXmsr5z5Zqi5%2BORhoZr3hY4F7A%40mail.gmail.com.

Re: [v8-users] Performance mystery with largish heaps

[Jakob Gruber]

+Ulan Degenbaev 

On Thu, Sep 5, 2019 at 9:06 PM Philip Zeyliger 
wrote:

> Hi,
>
> I'm running into what seems to be a lot of v8 GC activity when piping a
> 1GB file to /dev/null. The performance varies considerably depending on
> whether or not I have an empty heap or one that I've filled to the tune of
> 500MB. This is happening within node, but everything I can find is pointing
> to some interaction between Node's IO and v8 garbage collection.
>
> My reproduction is at
> https://gist.githubusercontent.com/philz/3e55a1a3377797d1fbc47b10a219ec6f/raw/1a6faadd60a0b920db08b39b759a2065bcd25831/slow.js;
> running this with node will see the first 5 iterations happen more quickly
> than the second 5 iterations.
>
> Looking at --trace_gc, both the "slow" and "fast" paths do ~80 mark-sweep
> collections, but, when the heap is small, these take ~1-2ms whereas in the
> slow case (bigger heap) they take ~200ms.
>
> Example slow: [2417:0x55f66b6913b0] 6858 ms: Mark-sweep 5.5 (11.0) ->
> 4.3 (11.0) MB, 1.0 / 0.0 ms  (+ 2.4 ms in 4 steps since start of marking,
> biggest step 1.0 ms, walltime since start of marking 3 ms) finalize
> incremental marking via task GC in old space requested
> Example fast: [2417:0x55f66b6913b0]35062 ms: Mark-sweep 770.9 (888.5)
> -> 769.6 (888.5) MB, 2.8 / 0.0 ms  (+ 224.0 ms in 247 steps since start of
> marking, biggest step 3.3 ms, walltime since start of marking 227 ms)
> finalize incremental marking via task GC in old space requested
>
> It's not surprising that mark-sweep takes longer on a bigger heap, but
> it's reclaiming very little space, and I'd have expected it to either grow
> the heap or use an incremental collector.
>
> I'd appreciate any suggestions you may have! (The real use case here
> involves JSON.stringify() and uploading to S3 using the AWS SDK, but this
> is the whittled down mystery.)
>
> Thanks,
>
> -- Philip
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/c25cc22b-9c76-4657-bb45-927238bff613%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oOh3BZJE1RhBp-WGfF2L8AJ39fuR2BxeHeYY_HScyMAmA%40mail.gmail.com.

Re: [v8-users] Snapshot blob includes java script code with comments

[Jakob Gruber]

On Tue, Sep 3, 2019 at 1:39 PM Jakob Kummerow 
wrote:

> The snapshot will typically contain both the original JavaScript source
> and the bytecode for functions. Function.prototype.toString needs the
> source, so not including that in the snapshot would be a spec violation.
>

Bytecode is usually also cleared (and later compiled lazily at runtime)
unless FunctionCodeHandling::kKeep is passed.


>
> On Tue, Sep 3, 2019 at 1:23 PM Oleg Beletski 
> wrote:
>
>> I viewed content of the custom generated snapshot and was surprised to
>> see that  it contains almost unmodified blocks of java script with comments
>> in it.
>>
>>
>> Is that normal behavior? Is there away to get more efficient processing
>> of java script before snapshot created?  Our snapshot creation code is
>> similar code in mksnapshot.
>>
>
You could minify manually and/or use FunctionCodeHandling::kKeep.


>
>> Thanks,
>> Oleg
>>
>> --
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/v8-users/544f718d-70dc-494c-9e92-7b4eb0ece0d8%40googlegroups.com
>> 
>> .
>>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/CAKSzg3Rwm_edNaMQ--9E61j1mV7KYUmE3d81R6HCWDaVWL25nQ%40mail.gmail.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oO1huoo2XB65X83aONqHUipuzqnVReHah0Ac3zHwH8viQ%40mail.gmail.com.

Re: [v8-users] Create heap snapshot for x86 from 64 bit process

[Jakob Gruber]

On Mon, Aug 26, 2019 at 10:41 AM Darin Dimitrov 
wrote:

> Is it possible to create heap snapshot using the "mksnapshot" tool for x86
> or armeabi-v7a CPU architectures from a 64 bit process. If yes, what are
> the steps to build such "mksnapshot" executable?
>

Unfortunately, no. Cross-bitness builds are not supported at the moment.
Would building inside a Linux VM be an option?


> Mac OS Catalina drops support for 32 bit executables and we would like to
> still be able to produce heap snapshots for x86 or armeabi-v7a
> architectures on this host OS.
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/aeb27954-4333-4a50-8f0f-273dbee63923%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oO%3DFXpqY_8%2BYy32c%3Dnzr8sjLaAriTKKaCb812jahAhNDg%40mail.gmail.com.

Re: [v8-users] d8.exe crashed when running a script

[Jakob Gruber]

Sounds like a stack overflow in the regexp compiler while compiling a huge
pattern. Feel free to file a bug (please include a backtrace). Also see
https://crbug.com/v8/9378.

On Thu, Aug 22, 2019 at 10:45 AM qinghai xiao  wrote:

> Version: 7.6.303.22
> OS: Windows
> Architecture: x86
>
> *What steps will reproduce the problem?*
> *1.*type this script in v8_shell.exe and d8.exe:
>
> String.prototype.split.call('aa', new
> RegExp(Array(4096).join(String.fromCharCode(36, 94)) +
> Array(1025).join(String.fromCharCode(126, 29)) +
> Array(257).join(String.fromCharCode(101, 10, 43)), 'i'))
>
> *What is the expected output?*
> When I use Chrome 76.0.3809.80 (v8 version 7.6.303.24), this script output
> is as follows:
> ["aa"]
>
> *What do you see instead?*
> Then I run these codes to tracking in vs2017:
>
> v8::Local source = v8::String::NewFromUtf8(isolate,
> "String.prototype.split.call('aa', new
> RegExp(Array(4096).join(String.fromCharCode(36, 94)) +
> Array(1025).join(String.fromCharCode(126, 29)) +
> Array(257).join(String.fromCharCode(101, 10, 43)),
> 'i'))",v8::NewStringType::kNormal).ToLocalChecked();
>
> v8::Local script =v8::Script::Compile(context,
> source).ToLocalChecked();
>
> v8::Local result = script->Run(context).ToLocalChecked();
>
> v8::String::Utf8Value utf8(isolate, result);
>
> printf("%s\n", *utf8);
>
> then I got a stark overflow error.I want to know if this represents a
> problem in my compilation process.
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/CAJvF0Q25DHnO7ABOM477nj8WkiACemHfvX%3DpsHqqM0bOiBGbCA%40mail.gmail.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oO4K%3D19XO0vvqrugiceduUVyjJWt1G-aOJOMbq80NVR3w%40mail.gmail.com.

Re: [v8-users] jitless mode broken on ARM64

[Jakob Gruber]

The CL you pointed to experimentally enables it for arm64 (so also iOS). I
don't know what the cause is but yes, pointer compression should work in
jitless mode.

On Thu, Aug 8, 2019 at 8:13 AM Darin Dimitrov 
wrote:

> Thanks for the quick tip. Shouldn't pointer compression be disabled by
> default when target_os="ios"? Or is it just some issue that will be fixed
> and we will be able to use pointer compression in jitless mode in the
> future?
>
> On Thursday, August 8, 2019 at 7:49:16 AM UTC+3, Jakob Gruber wrote:
>>
>> Darin, thanks for reporting this. You can disable pointer compression
>> with the 'v8_enable_pointer_compression = false' gn flag.
>>
>> On Wed, Aug 7, 2019 at 5:24 PM Santiago Aboy Solanes 
>> wrote:
>>
>>> Looks to be the same as
>>> https://bugs.chromium.org/p/v8/issues/detail?id=9588
>>>
>>> On Wed, Aug 7, 2019 at 1:13 PM Jakob Gruber  wrote:
>>>
>>>> +Santiago Aboy Solanes
>>>>
>>>> On Wed, Aug 7, 2019 at 2:09 PM Darin Dimitrov 
>>>> wrote:
>>>>
>>>>> I have cross compiled V8 for iOS
>>>>> <https://v8.dev/docs/cross-compile-ios> and running in "--jitless"
>>>>> <https://v8.dev/blog/jitless> mode on an arm64 device (iPhone 6).
>>>>>
>>>>> Everything has been working smoothly until the following commit which
>>>>> appears to have broken it:
>>>>> https://chromium.googlesource.com/v8/v8.git/+/d1a4706af97dfd1576c7eb505745c6f864f4be06
>>>>>
>>>>> I am getting the following error when creating the isolate:
>>>>>
>>>>> *#*
>>>>>
>>>>> *# Fatal error in , line 0*
>>>>>
>>>>> *# Fatal process out of memory: Failed to reserve memory for new V8
>>>>> Isolate*
>>>>>
>>>>> *#*
>>>>>
>>>>> *#*
>>>>>
>>>>> *#*
>>>>>
>>>>> *#FailureMessage Object: 0x16fa225c8*
>>>>>
>>>>> * C stack trace ===*
>>>>>
>>>>>
>>>>> *0   TestApp 0x000101b19508
>>>>> v8::base::debug::StackTrace::StackTrace() + 24*
>>>>>
>>>>> *1   TestApp 0x000101b1bc68
>>>>> v8::platform::(anonymous namespace)::PrintStackTrace() + 24*
>>>>>
>>>>> *2   TestApp 0x000101b159d4
>>>>> V8_Fatal(char const*, ...) + 204*
>>>>>
>>>>> *3   TestApp 0x000101285124
>>>>> v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char
>>>>> const*, bool) + 88*
>>>>>
>>>>> *4   TestApp 0x0001014ecf38
>>>>> v8::internal::IsolateAllocator::CommitPagesForIsolate(unsigned long) + 0*
>>>>>
>>>>> *5   TestApp 0x0001014ed09c
>>>>> v8::internal::IsolateAllocator::IsolateAllocator(v8::internal::IsolateAllocationMode)
>>>>> + 44*
>>>>>
>>>>> *6   TestApp 0x0001014f3b5c
>>>>> v8::internal::Isolate::New(v8::internal::IsolateAllocationMode) + 36*
>>>>>
>>>>> *7   TestApp 0x0001012a0328
>>>>> v8::Isolate::New(v8::Isolate::CreateParams const&) + 24*
>>>>>
>>>>> *8   TestApp 0x000101089d1c
>>>>> tns::Runtime::Init(std::__1::basic_string>>>> std::__1::char_traits, std::__1::allocator > const&) + 476*
>>>>>
>>>>> *9   TestApp 0x000101089834
>>>>> tns::Runtime::InitAndRunMainScript(std::__1::basic_string>>>> std::__1::char_traits, std::__1::allocator > const&) + 60*
>>>>>
>>>>> *10  TestApp 0x000101178350
>>>>> +[NativeScript start:] + 364*
>>>>>
>>>>> *11  TestApp 0x0001003f3b10 main +
>>>>> 80*
>>>>>
>>>>> *12  libdyld.dylib   0x0002021f68e0
>>>>>  + 4*
>>>>>
>>>>>
>>>>>
>>>>>

Re: [v8-users] jitless mode broken on ARM64

[Jakob Gruber]

Darin, thanks for reporting this. You can disable pointer compression with
the 'v8_enable_pointer_compression = false' gn flag.

On Wed, Aug 7, 2019 at 5:24 PM Santiago Aboy Solanes 
wrote:

> Looks to be the same as
> https://bugs.chromium.org/p/v8/issues/detail?id=9588
>
> On Wed, Aug 7, 2019 at 1:13 PM Jakob Gruber  wrote:
>
>> +Santiago Aboy Solanes 
>>
>> On Wed, Aug 7, 2019 at 2:09 PM Darin Dimitrov 
>> wrote:
>>
>>> I have cross compiled V8 for iOS <https://v8.dev/docs/cross-compile-ios> and
>>> running in "--jitless" <https://v8.dev/blog/jitless> mode on an arm64
>>> device (iPhone 6).
>>>
>>> Everything has been working smoothly until the following commit which
>>> appears to have broken it:
>>> https://chromium.googlesource.com/v8/v8.git/+/d1a4706af97dfd1576c7eb505745c6f864f4be06
>>>
>>> I am getting the following error when creating the isolate:
>>>
>>> *#*
>>>
>>> *# Fatal error in , line 0*
>>>
>>> *# Fatal process out of memory: Failed to reserve memory for new V8
>>> Isolate*
>>>
>>> *#*
>>>
>>> *#*
>>>
>>> *#*
>>>
>>> *#FailureMessage Object: 0x16fa225c8*
>>>
>>> * C stack trace ===*
>>>
>>>
>>> *0   TestApp 0x000101b19508
>>> v8::base::debug::StackTrace::StackTrace() + 24*
>>>
>>> *1   TestApp 0x000101b1bc68
>>> v8::platform::(anonymous namespace)::PrintStackTrace() + 24*
>>>
>>> *2   TestApp 0x000101b159d4
>>> V8_Fatal(char const*, ...) + 204*
>>>
>>> *3   TestApp 0x000101285124
>>> v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char
>>> const*, bool) + 88*
>>>
>>> *4   TestApp 0x0001014ecf38
>>> v8::internal::IsolateAllocator::CommitPagesForIsolate(unsigned long) + 0*
>>>
>>> *5   TestApp 0x0001014ed09c
>>> v8::internal::IsolateAllocator::IsolateAllocator(v8::internal::IsolateAllocationMode)
>>> + 44*
>>>
>>> *6   TestApp 0x0001014f3b5c
>>> v8::internal::Isolate::New(v8::internal::IsolateAllocationMode) + 36*
>>>
>>> *7   TestApp 0x0001012a0328
>>> v8::Isolate::New(v8::Isolate::CreateParams const&) + 24*
>>>
>>> *8   TestApp 0x000101089d1c
>>> tns::Runtime::Init(std::__1::basic_string>> std::__1::char_traits, std::__1::allocator > const&) + 476*
>>>
>>> *9   TestApp 0x000101089834
>>> tns::Runtime::InitAndRunMainScript(std::__1::basic_string>> std::__1::char_traits, std::__1::allocator > const&) + 60*
>>>
>>> *10  TestApp 0x000101178350
>>> +[NativeScript start:] + 364*
>>>
>>> *11  TestApp 0x0001003f3b10 main +
>>> 80*
>>>
>>> *12  libdyld.dylib   0x0002021f68e0
>>>  + 4*
>>>
>>>
>>>
>>> From what I can see pointer compression has been enabled on ARM64 in
>>> this commit. Could you spot how this might have affected --jitless mode and
>>> what would be the proper way to fix 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/v8-users/600728f0-f7b1-4d16-a47a-8873ef61af97%40googlegroups.com
>>> <https://groups.google.com/d/msgid/v8-users/600728f0-f7b1-4d16-a47a-8873ef61af97%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oM2f1n8orK9XifhKYbvYBnkRYCUjRFgLM_0Roy2OLyeCA%40mail.gmail.com.

Re: [v8-users] jitless mode broken on ARM64

[Jakob Gruber]

+Santiago Aboy Solanes 

On Wed, Aug 7, 2019 at 2:09 PM Darin Dimitrov 
wrote:

> I have cross compiled V8 for iOS  and
> running in "--jitless"  mode on an arm64
> device (iPhone 6).
>
> Everything has been working smoothly until the following commit which
> appears to have broken it:
> https://chromium.googlesource.com/v8/v8.git/+/d1a4706af97dfd1576c7eb505745c6f864f4be06
>
> I am getting the following error when creating the isolate:
>
> *#*
>
> *# Fatal error in , line 0*
>
> *# Fatal process out of memory: Failed to reserve memory for new V8
> Isolate*
>
> *#*
>
> *#*
>
> *#*
>
> *#FailureMessage Object: 0x16fa225c8*
>
> * C stack trace ===*
>
>
> *0   TestApp 0x000101b19508
> v8::base::debug::StackTrace::StackTrace() + 24*
>
> *1   TestApp 0x000101b1bc68
> v8::platform::(anonymous namespace)::PrintStackTrace() + 24*
>
> *2   TestApp 0x000101b159d4
> V8_Fatal(char const*, ...) + 204*
>
> *3   TestApp 0x000101285124
> v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char
> const*, bool) + 88*
>
> *4   TestApp 0x0001014ecf38
> v8::internal::IsolateAllocator::CommitPagesForIsolate(unsigned long) + 0*
>
> *5   TestApp 0x0001014ed09c
> v8::internal::IsolateAllocator::IsolateAllocator(v8::internal::IsolateAllocationMode)
> + 44*
>
> *6   TestApp 0x0001014f3b5c
> v8::internal::Isolate::New(v8::internal::IsolateAllocationMode) + 36*
>
> *7   TestApp 0x0001012a0328
> v8::Isolate::New(v8::Isolate::CreateParams const&) + 24*
>
> *8   TestApp 0x000101089d1c
> tns::Runtime::Init(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&) + 476*
>
> *9   TestApp 0x000101089834
> tns::Runtime::InitAndRunMainScript(std::__1::basic_string std::__1::char_traits, std::__1::allocator > const&) + 60*
>
> *10  TestApp 0x000101178350
> +[NativeScript start:] + 364*
>
> *11  TestApp 0x0001003f3b10 main + 80*
>
> *12  libdyld.dylib   0x0002021f68e0 
> + 4*
>
>
>
> From what I can see pointer compression has been enabled on ARM64 in this
> commit. Could you spot how this might have affected --jitless mode and what
> would be the proper way to fix 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/600728f0-f7b1-4d16-a47a-8873ef61af97%40googlegroups.com
> 
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oPC_gnU3dGbzvr1KRoexRe1wDqBOVGax%2B4FHsqXyhKuyQ%40mail.gmail.com.

Re: [v8-users] Re: v8::Isolate::New works on 7.2, fails on 7.3+

[Jakob Gruber]

Glad it helped!

On Fri, Jul 19, 2019 at 3:13 PM Christopher Nelson 
wrote:

> Since this does seem to have fixed the problem on macOS, I wondered why it
> might be a problem. It looks to me like the libc++ being built is built in
> Release+Asserts mode even when I ask for v8 to be built in debug mode. I
> wonder if this ends up being the problem when debug code is expecting one
> thing, but instead it is getting a release version.
>
> In any case, I think that I am going to look into modifying the GN build
> for v8 to allow using the default or "system" libc++ instead of just being
> able to use the "default" c++ standard library or the custom libc++
> library. If you or anyone else can give me some guidance on that, I'd be
> happy to contribute it back. I'm sure I can't be the only person this has
> bitten and frustrated.
>

 Nico fyi.


>
> Thanks again for all the help!
>
> On Thursday, July 18, 2019 at 9:52:49 AM UTC-4, Jakob Gruber wrote:
>>
>>
>> On Thu, Jul 18, 2019 at 3:10 PM Christopher Nelson 
>> wrote:
>>
>>> I appreciate that info, and I have read it. However, that is very
>>> unlikely to be the problem here. In this case I am not passing any C++ ABI
>>> objects between libraries, I'm just creating a new isolate. The
>>> reproduction is so minimal and so simple that is seems very unlikely that
>>> libc++ is at fault here. It happens deep inside the isolate initialization.
>>>
>>
>> I see. It sounds like you have a full repro to share; could you perhaps
>> open a bug at crbug.com/v8/new, include the repro, and I will try to
>> have a look next week.
>>
>>
>>>
>>> On Thursday, July 18, 2019 at 8:43:42 AM UTC-4, Jakob Gruber wrote:
>>>>
>>>> On Thu, Jul 18, 2019 at 2:32 PM Christopher Nelson 
>>>> wrote:
>>>>
>>>>> I'm not using the same exact libc++, no. I don't have a problem doing
>>>>> that, but I'd like to link v8 against MY libc++ instead of linking my app
>>>>> against v8's libc++. The reason is:  I am compiling against a number of
>>>>> libraries, all of which are compiled against my libc++. Trying to change
>>>>> them all to compile against V8's libc++ is probably not possible.
>>>>>
>>>>> I'm also a little suspicious that libc++ is the problem here because
>>>>> it works fine in release; which I would expect to be _more_ sensitive. In
>>>>> any case, if you can tell me how or point me to instructions on how to 
>>>>> tell
>>>>> V8 which libc++ to use I will very happily implement that.
>>>>>
>>>>
>>>> I assume building with a libcxx that is neither the system libcxx nor
>>>> V8's custom libcxx will need manual work. I'm not an expert on this either,
>>>> I've just seen folks run into this fairly frequently in recent times.
>>>>
>>>> Here's where all of my infos come from: https://crbug.com/v8/9150#c2.
>>>> Maybe this will help clarify.
>>>>
>>>> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/b77de9a9-2b84-4726-a411-5eb3a4eb5894%40googlegroups.com
> <https://groups.google.com/d/msgid/v8-users/b77de9a9-2b84-4726-a411-5eb3a4eb5894%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oPgWztNjrdTNOWw1X7iEcLteVyqVYYPmaMiUf%3DDjb2%3DMQ%40mail.gmail.com.

Re: [v8-users] Re: v8::Isolate::New works on 7.2, fails on 7.3+

[Jakob Gruber]

On Thu, Jul 18, 2019 at 3:10 PM Christopher Nelson 
wrote:

> I appreciate that info, and I have read it. However, that is very unlikely
> to be the problem here. In this case I am not passing any C++ ABI objects
> between libraries, I'm just creating a new isolate. The reproduction is so
> minimal and so simple that is seems very unlikely that libc++ is at fault
> here. It happens deep inside the isolate initialization.
>

I see. It sounds like you have a full repro to share; could you perhaps
open a bug at crbug.com/v8/new, include the repro, and I will try to have a
look next week.


>
> On Thursday, July 18, 2019 at 8:43:42 AM UTC-4, Jakob Gruber wrote:
>>
>> On Thu, Jul 18, 2019 at 2:32 PM Christopher Nelson 
>> wrote:
>>
>>> I'm not using the same exact libc++, no. I don't have a problem doing
>>> that, but I'd like to link v8 against MY libc++ instead of linking my app
>>> against v8's libc++. The reason is:  I am compiling against a number of
>>> libraries, all of which are compiled against my libc++. Trying to change
>>> them all to compile against V8's libc++ is probably not possible.
>>>
>>> I'm also a little suspicious that libc++ is the problem here because it
>>> works fine in release; which I would expect to be _more_ sensitive. In any
>>> case, if you can tell me how or point me to instructions on how to tell V8
>>> which libc++ to use I will very happily implement that.
>>>
>>
>> I assume building with a libcxx that is neither the system libcxx nor
>> V8's custom libcxx will need manual work. I'm not an expert on this either,
>> I've just seen folks run into this fairly frequently in recent times.
>>
>> Here's where all of my infos come from: https://crbug.com/v8/9150#c2.
>> Maybe this will help clarify.
>>
>>
>>>
>>> On Thursday, July 18, 2019 at 1:22:04 AM UTC-4, Jakob Gruber wrote:
>>>>
>>>> On Wed, Jul 17, 2019 at 5:48 PM Christopher Nelson 
>>>> wrote:
>>>>
>>>>> Thank you so much for the help that has been provided so far. Sadly, I
>>>>> tried both of these suggestions without success.
>>>>>
>>>>> First, I removed all of the build arguments except:
>>>>>
>>>>> is_debug = true
>>>>> target_cpu = "x64"
>>>>> v8_monolithic = true
>>>>> v8_enable_i18n_support = false
>>>>>
>>>>> I built this with much the same results. I also duplicated this
>>>>> problem on macOS with debug. (Release works fine on both platforms.)
>>>>>
>>>>> I also tried setting "use_custom_libcxx = false", but we use libc++
>>>>> (the one shipped with clang) on Linux and macOS. I couldn't find a way to
>>>>> tell v8 to set -stdlib libc++ without it also wanting that to be the 
>>>>> custom
>>>>> one v8 compiles. If I set this value to false then the flag is omitted and
>>>>> it picks up libstdc++ by default, which results in a lot of link errors.
>>>>>
>>>>
>>>> Just to confirm: are you linking your project against the same custom
>>>> libcxx that V8 uses? If yes, then we need to start looking elsewhere (than
>>>> use_custom_libcxx) for the problem. If no, that would still be my 
>>>> suspicion.
>>>>
>>>> Note also how the backtrace below is in a completely different spot in
>>>> V8 than the one you posted before. And this time in deallocate (before it
>>>> was in an allocation).
>>>>
>>>>
>>>>>
>>>>> My colleague and I have managed to duplicate this in the most trivial
>>>>> hello-world program, which just initializes the engine and creates an
>>>>> isolate.
>>>>>
>>>>> The interesting thing is that the d8 app created by the v8 build is
>>>>> fine. It is only applications that link against the v8 monolith outside 
>>>>> the
>>>>> v8 build that experience the problem. We also accidentally noted that if 
>>>>> we
>>>>> initialize the engine twice, the problem goes away.
>>>>>
>>>>
>>>>> As I say, this wasn't a problem in 7.2, but in 7.3+ it's happening
>>>>> with perfect reproducibility. For the record, here is the backtrace:
>>>>>
>>>>> #0  __GI_raise (sig=sig@entry=6) at
>>>>> ../sysdeps/unix/sysv/linux/raise.c:50
>>>>> #1  0x7ff

Re: [v8-users] Re: v8::Isolate::New works on 7.2, fails on 7.3+

[Jakob Gruber]

On Thu, Jul 18, 2019 at 2:32 PM Christopher Nelson 
wrote:

> I'm not using the same exact libc++, no. I don't have a problem doing
> that, but I'd like to link v8 against MY libc++ instead of linking my app
> against v8's libc++. The reason is:  I am compiling against a number of
> libraries, all of which are compiled against my libc++. Trying to change
> them all to compile against V8's libc++ is probably not possible.
>
> I'm also a little suspicious that libc++ is the problem here because it
> works fine in release; which I would expect to be _more_ sensitive. In any
> case, if you can tell me how or point me to instructions on how to tell V8
> which libc++ to use I will very happily implement that.
>

I assume building with a libcxx that is neither the system libcxx nor V8's
custom libcxx will need manual work. I'm not an expert on this either, I've
just seen folks run into this fairly frequently in recent times.

Here's where all of my infos come from: https://crbug.com/v8/9150#c2. Maybe
this will help clarify.


>
> On Thursday, July 18, 2019 at 1:22:04 AM UTC-4, Jakob Gruber wrote:
>>
>> On Wed, Jul 17, 2019 at 5:48 PM Christopher Nelson 
>> wrote:
>>
>>> Thank you so much for the help that has been provided so far. Sadly, I
>>> tried both of these suggestions without success.
>>>
>>> First, I removed all of the build arguments except:
>>>
>>> is_debug = true
>>> target_cpu = "x64"
>>> v8_monolithic = true
>>> v8_enable_i18n_support = false
>>>
>>> I built this with much the same results. I also duplicated this problem
>>> on macOS with debug. (Release works fine on both platforms.)
>>>
>>> I also tried setting "use_custom_libcxx = false", but we use libc++ (the
>>> one shipped with clang) on Linux and macOS. I couldn't find a way to tell
>>> v8 to set -stdlib libc++ without it also wanting that to be the custom one
>>> v8 compiles. If I set this value to false then the flag is omitted and it
>>> picks up libstdc++ by default, which results in a lot of link errors.
>>>
>>
>> Just to confirm: are you linking your project against the same custom
>> libcxx that V8 uses? If yes, then we need to start looking elsewhere (than
>> use_custom_libcxx) for the problem. If no, that would still be my suspicion.
>>
>> Note also how the backtrace below is in a completely different spot in V8
>> than the one you posted before. And this time in deallocate (before it was
>> in an allocation).
>>
>>
>>>
>>> My colleague and I have managed to duplicate this in the most trivial
>>> hello-world program, which just initializes the engine and creates an
>>> isolate.
>>>
>>> The interesting thing is that the d8 app created by the v8 build is
>>> fine. It is only applications that link against the v8 monolith outside the
>>> v8 build that experience the problem. We also accidentally noted that if we
>>> initialize the engine twice, the problem goes away.
>>>
>>
>>> As I say, this wasn't a problem in 7.2, but in 7.3+ it's happening with
>>> perfect reproducibility. For the record, here is the backtrace:
>>>
>>> #0  __GI_raise (sig=sig@entry=6) at
>>> ../sysdeps/unix/sysv/linux/raise.c:50
>>> #1  0x77b5a535 in __GI_abort () at abort.c:79
>>> #2  0x77bc1726 in __libc_message (action=action@entry=do_abort,
>>> fmt=fmt@entry=0x77ce7952 "%s\n") at
>>> ../sysdeps/posix/libc_fatal.c:181
>>> #3  0x77bc859a in malloc_printerr (str=str@entry=0x77ce5a9b
>>> "free(): invalid pointer") at malloc.c:5352
>>> #4  0x77bca3cc in _int_free (av=, p=>> out>, have_lock=) at malloc.c:4181
>>> #5  0x04da70e5 in __do_call () at
>>> ../../buildtools/third_party/libc++/trunk/include/new:319
>>> #6  __do_deallocate_handle_size () at
>>> ../../buildtools/third_party/libc++/trunk/include/new:277
>>> #7  __do_deallocate_handle_size_align () at
>>> ../../buildtools/third_party/libc++/trunk/include/new:247
>>> #8  __libcpp_deallocate () at
>>> ../../buildtools/third_party/libc++/trunk/include/new:325
>>> #9  deallocate () at
>>> ../../buildtools/third_party/libc++/trunk/include/memory:1816
>>> #10 deallocate () at
>>> ../../buildtools/third_party/libc++/trunk/include/memory:1554
>>> #11 ~basic_string () at
>>> ../../buildtools/third_party/libc++/trunk/include/string:2138
>>> #12 Print () at ../../src/code-stub-assem

Re: [v8-users] Loading unaligned UTF-16 data in 7.6

[Jakob Gruber]

On Wed, Jul 17, 2019 at 10:49 PM Alex Kodat  wrote:

> In Reland "[runtime] Speed up String::IsOneByte", the following check was
> added to NonOneByteStart in src/objects/string.h:
>
>   DCHECK(IsAligned(reinterpret_cast(chars), sizeof(uc16)));
>
> This is part of the very clever word at a time detection of code points >
> 256. Unfortunately for us, this code ends up getting called for data we
> pass to String::NewFromTwoByte. And while the name gives one pause, the
> comment says
>
> /** Allocates a new string from UTF-16 data.*/
>
> so we've been using this against UTF-16 data which, UTF-16 being a
> serialization mechanism might not be two-byte aligned (ours is often in
> protocol buffer data). In any case, String::NewFromTwoByte
> calls Factory::NewStringFromTwoByte with the unaligned string which then
> calls String::IsOneByte with the unaligned string which then fails with the
> DCHECK. Without the DCHECK it works because the code that's scanning for
> the start of word alignment works fine for non-two-byte aligned data so
> this is only really an issue for debug builds though admittedly the
> non-one-byte scan won't be nearly as efficient for non-aligned data so
> maybe the code is doing us a favor by hitting us on the head.
>
> For non-two-byte aligned data, the clever algorithm could still be made to
> work by flipping the endian-specific word mask and a bit of up-front
> fiddling but far be it for me to advocate anyone going to that trouble
> though I guess if I were told that such a change would be accepted i'd be
> willing to contribute such a fix, myself. Another way to fix it would be to
> create the string in the heap as a two-byte string and then scan the
> aligned data in the heap, flipping the one-byte bit (or whatever indicates
> one-byte) in the string object. But haven't researched whether there is a
> call to do this bit flip.
>
> In any case, it doesn't seem nice that V8 no longer has an unaligned
> UTF-16 to string conversion mechanism, at least not one that works for
> debug builds.
>
> Opinions?
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/7f027ba5-d190-45a0-ad94-954e61ec8a4f%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oPiZ2ZftpOUvOSaXSkvntbVQVoPaJHLekMWiam7yUYJcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Re: v8::Isolate::New works on 7.2, fails on 7.3+

[Jakob Gruber]

On Wed, Jul 17, 2019 at 5:48 PM Christopher Nelson 
wrote:

> Thank you so much for the help that has been provided so far. Sadly, I
> tried both of these suggestions without success.
>
> First, I removed all of the build arguments except:
>
> is_debug = true
> target_cpu = "x64"
> v8_monolithic = true
> v8_enable_i18n_support = false
>
> I built this with much the same results. I also duplicated this problem on
> macOS with debug. (Release works fine on both platforms.)
>
> I also tried setting "use_custom_libcxx = false", but we use libc++ (the
> one shipped with clang) on Linux and macOS. I couldn't find a way to tell
> v8 to set -stdlib libc++ without it also wanting that to be the custom one
> v8 compiles. If I set this value to false then the flag is omitted and it
> picks up libstdc++ by default, which results in a lot of link errors.
>

Just to confirm: are you linking your project against the same custom
libcxx that V8 uses? If yes, then we need to start looking elsewhere (than
use_custom_libcxx) for the problem. If no, that would still be my suspicion.

Note also how the backtrace below is in a completely different spot in V8
than the one you posted before. And this time in deallocate (before it was
in an allocation).


>
> My colleague and I have managed to duplicate this in the most trivial
> hello-world program, which just initializes the engine and creates an
> isolate.
>
> The interesting thing is that the d8 app created by the v8 build is fine.
> It is only applications that link against the v8 monolith outside the v8
> build that experience the problem. We also accidentally noted that if we
> initialize the engine twice, the problem goes away.
>

> As I say, this wasn't a problem in 7.2, but in 7.3+ it's happening with
> perfect reproducibility. For the record, here is the backtrace:
>
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x77b5a535 in __GI_abort () at abort.c:79
> #2  0x77bc1726 in __libc_message (action=action@entry=do_abort,
> fmt=fmt@entry=0x77ce7952 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
> #3  0x77bc859a in malloc_printerr (str=str@entry=0x77ce5a9b
> "free(): invalid pointer") at malloc.c:5352
> #4  0x77bca3cc in _int_free (av=, p= out>, have_lock=) at malloc.c:4181
> #5  0x04da70e5 in __do_call () at
> ../../buildtools/third_party/libc++/trunk/include/new:319
> #6  __do_deallocate_handle_size () at
> ../../buildtools/third_party/libc++/trunk/include/new:277
> #7  __do_deallocate_handle_size_align () at
> ../../buildtools/third_party/libc++/trunk/include/new:247
> #8  __libcpp_deallocate () at
> ../../buildtools/third_party/libc++/trunk/include/new:325
> #9  deallocate () at
> ../../buildtools/third_party/libc++/trunk/include/memory:1816
> #10 deallocate () at
> ../../buildtools/third_party/libc++/trunk/include/memory:1554
> #11 ~basic_string () at
> ../../buildtools/third_party/libc++/trunk/include/string:2138
> #12 Print () at ../../src/code-stub-assembler.cc:13702
> #13 0x051e254d in LoadKeyValuePairNoSideEffects () at
> gen/torque-generated/builtins-collections-from-dsl-gen.cc:533
> #14 0x04cfc7e1 in AddConstructorEntry () at
> ../../src/builtins/builtins-collections-gen.cc:163
> #15 0x04d10fb6 in operator() () at
> ../../src/builtins/builtins-collections-gen.cc:270
> #16 __invoke<(lambda at
> ../../src/builtins/builtins-collections-gen.cc:267:22) &,
> v8::internal::compiler::Node *> () at
> ../../buildtools/third_party/libc++/trunk/include/type_traits:4399
> #17 __call<(lambda at
> ../../src/builtins/builtins-collections-gen.cc:267:22) &,
> v8::internal::compiler::Node *> () at
> ../../buildtools/third_party/libc++/trunk/include/__functional_base:348
> #18 operator() () at
> ../../buildtools/third_party/libc++/trunk/include/functional:1531
> #19 __call_impl ../../src/builtins/builtins-collections-gen.cc:267:22),
> std::__1::allocator<(lambda at
> ../../src/builtins/builtins-collections-gen.cc:267:22)>, void
> (v8::internal::compiler::Node *)> > () at
> ../../buildtools/third_party/libc++/trunk/include/functional:2014
> #20 0x04d76fb1 in operator() () at
> ../../buildtools/third_party/libc++/trunk/include/functional:2127
> #21 operator() () at
> ../../buildtools/third_party/libc++/trunk/include/functional:2351
> #22 BuildFastLoop () at ../../src/code-stub-assembler.cc:10997
> #23 0x04cfd8e0 in BuildFastLoop () at
> ../../src/code-stub-assembler.h:3062
> #24 AddConstructorEntriesFromFastJSArray () at
> ../../src/builtins/builtins-collections-gen.cc:278
> #25 0x04cfcd55 in AddConstructorEntries () at
> ../../src/builtins/builtins-collections-gen.cc:207
> #26 0x04cfeebf in GenerateConstructor () at
> ../../src/builtins/builtins-collections-gen.cc:416
> #27 0x04cff596 in GenerateMapConstructorImpl () at
> ../../src/builtins/builtins-collections-gen.cc:740
> #28 0x04cff3ea in Generate_MapConstructor () at
> 

Re: [v8-users] Re: v8::Isolate::New works on 7.2, fails on 7.3+

[Jakob Gruber]

On Tue, Jul 16, 2019 at 11:13 AM Dan Elphick  wrote:

> Does the problem go away if you change the build flags to just
> target_cpu="x64" and maybe just is_component_build = false? If so can you
> try adding them back in one at a time to see which one triggers it (I'd
> probably start with v8_monolithic since the v8_enable_* flags there seem
> unlikely to be the cause?
>

That reminds me, it could be related to use_custom_libcxx (a mismatch in
libcxx used for V8 and the embedding project). Have you tried
'use_custom_libcxx = false'?


>
> On Tuesday, July 16, 2019 at 6:18:48 AM UTC+1, Jakob Gruber wrote:
>>
>> Looks like allocation of the new string here
>> <https://cs.chromium.org/chromium/src/v8/src/interpreter/interpreter.cc?l=277=5bf6b8221240ae424bb2b19713bec7534125b9c5>
>> is failing. That code has been there since 71 though.
>>
>> On Mon, Jul 15, 2019 at 7:37 PM Christopher Nelson 
>> wrote:
>>
>>> I have found that actually, the problem is that DEBUG builds now throw
>>> this error on Linux, whereas release builds are fine. I have tried to
>>> determine if there are any flags my app needs to have or to omit when
>>> linking against the monolithic V8 lib on linux for debug. Any help would be
>>> appreciated!
>>>
>>> On Friday, July 12, 2019 at 4:54:39 PM UTC-4, Christopher Nelson wrote:
>>>>
>>>>
>>>> I have the following code, which works fine on v8 7.2:
>>>>
>>>> isolate::isolate() {
>>>>   create_params.array_buffer_allocator =
>>>>   v8
>>>> ::ArrayBuffer::Allocator::NewDefaultAllocator();
>>>>   i = v8::
>>>> Isolate::New(create_params);
>>>>   i->SetData(0,
>>>> this);
>>>>   }
>>>>
>>>>
>>>> However, when run on 7.3+ it yields this:
>>>>
>>>> #0  __memmove_sse2_unaligned_erms () at
>>>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:321
>>>> #1  0x77dc66d9 in std::__1::basic_string>>> std::__1::char_traits, std::__1::allocator >::append(char
>>>> const*, unsigned long) () from /lib/x86_64-linux-gnu/libc++.so.1
>>>> #2  0x044bbd79 in operator+,
>>>> std::__1::allocator > () at
>>>> ../../buildtools/third_party/libc++/trunk/include/string:4147
>>>> #3  operator() () at ../../src/interpreter/interpreter.cc:277
>>>> #4  __invoke<(lambda at ../../src/interpreter/interpreter.cc:270:19) &,
>>>> v8::internal::interpreter::Bytecode,
>>>> v8::internal::interpreter::OperandScale> () at
>>>> ../../buildtools/third_party/libc++/trunk/include/type_traits:4353
>>>> #5  __call<(lambda at ../../src/interpreter/interpreter.cc:270:19) &,
>>>> v8::internal::interpreter::Bytecode,
>>>> v8::internal::interpreter::OperandScale> () at
>>>> ../../buildtools/third_party/libc++/trunk/include/__functional_base:349
>>>> #6  operator() () at
>>>> ../../buildtools/third_party/libc++/trunk/include/functional:1527
>>>> #7  __call_impl>>> ../../src/interpreter/interpreter.cc:270:19), std::__1::allocator<(lambda
>>>> at ../../src/interpreter/interpreter.cc:270:19)>, void
>>>> (v8::internal::interpreter::Bytecode,
>>>> v8::internal::interpreter::OperandScale)> > () at
>>>> ../../buildtools/third_party/libc++/trunk/include/functional:2010
>>>> #8  0x044ba5f4 in operator() () at
>>>> ../../buildtools/third_party/libc++/trunk/include/functional:2123
>>>> #9  operator() () at
>>>> ../../buildtools/third_party/libc++/trunk/include/functional:2347
>>>> #10 ForEachBytecode () at ../../src/interpreter/interpreter.cc:251
>>>> #11 0x044ba834 in Initialize () at
>>>> ../../src/interpreter/interpreter.cc:270
>>>> #12 0x0452aa8b in Init () at ../../src/isolate.cc:3336
>>>> #13 0x048f72da in Initialize () at
>>>> ../../src/snapshot/snapshot-common.cc:50
>>>> #14 0x03e2c492 in Initialize () at ../../src/api.cc:8174
>>>> #15 0x03e2ca2f in New () at ../../src/api.cc:8196
>>>> #16 0x03d986bc in hiram::js::isolate::isolate
>>>> (this=0x7fffcf38) at ../../../../../engine/src/js/isolate.cpp:2

Re: [v8-users] Re: v8::Isolate::New works on 7.2, fails on 7.3+

[Jakob Gruber]

Looks like allocation of the new string here

is failing. That code has been there since 71 though.

On Mon, Jul 15, 2019 at 7:37 PM Christopher Nelson 
wrote:

> I have found that actually, the problem is that DEBUG builds now throw
> this error on Linux, whereas release builds are fine. I have tried to
> determine if there are any flags my app needs to have or to omit when
> linking against the monolithic V8 lib on linux for debug. Any help would be
> appreciated!
>
> On Friday, July 12, 2019 at 4:54:39 PM UTC-4, Christopher Nelson wrote:
>>
>>
>> I have the following code, which works fine on v8 7.2:
>>
>> isolate::isolate() {
>>   create_params.array_buffer_allocator =
>> v8::
>> ArrayBuffer::Allocator::NewDefaultAllocator();
>>   i = v8::Isolate
>> ::New(create_params);
>>   i->SetData(0, this);
>>
>> }
>>
>> However, when run on 7.3+ it yields this:
>>
>> #0  __memmove_sse2_unaligned_erms () at
>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:321
>> #1  0x77dc66d9 in std::__1::basic_string> std::__1::char_traits, std::__1::allocator >::append(char
>> const*, unsigned long) () from /lib/x86_64-linux-gnu/libc++.so.1
>> #2  0x044bbd79 in operator+,
>> std::__1::allocator > () at
>> ../../buildtools/third_party/libc++/trunk/include/string:4147
>> #3  operator() () at ../../src/interpreter/interpreter.cc:277
>> #4  __invoke<(lambda at ../../src/interpreter/interpreter.cc:270:19) &,
>> v8::internal::interpreter::Bytecode,
>> v8::internal::interpreter::OperandScale> () at
>> ../../buildtools/third_party/libc++/trunk/include/type_traits:4353
>> #5  __call<(lambda at ../../src/interpreter/interpreter.cc:270:19) &,
>> v8::internal::interpreter::Bytecode,
>> v8::internal::interpreter::OperandScale> () at
>> ../../buildtools/third_party/libc++/trunk/include/__functional_base:349
>> #6  operator() () at
>> ../../buildtools/third_party/libc++/trunk/include/functional:1527
>> #7  __call_impl> ../../src/interpreter/interpreter.cc:270:19), std::__1::allocator<(lambda
>> at ../../src/interpreter/interpreter.cc:270:19)>, void
>> (v8::internal::interpreter::Bytecode,
>> v8::internal::interpreter::OperandScale)> > () at
>> ../../buildtools/third_party/libc++/trunk/include/functional:2010
>> #8  0x044ba5f4 in operator() () at
>> ../../buildtools/third_party/libc++/trunk/include/functional:2123
>> #9  operator() () at
>> ../../buildtools/third_party/libc++/trunk/include/functional:2347
>> #10 ForEachBytecode () at ../../src/interpreter/interpreter.cc:251
>> #11 0x044ba834 in Initialize () at
>> ../../src/interpreter/interpreter.cc:270
>> #12 0x0452aa8b in Init () at ../../src/isolate.cc:3336
>> #13 0x048f72da in Initialize () at
>> ../../src/snapshot/snapshot-common.cc:50
>> #14 0x03e2c492 in Initialize () at ../../src/api.cc:8174
>> #15 0x03e2ca2f in New () at ../../src/api.cc:8196
>> #16 0x03d986bc in hiram::js::isolate::isolate
>> (this=0x7fffcf38) at ../../../../../engine/src/js/isolate.cpp:20
>> #17 0x03c93997 in C_A_T_C_HT_E_S_T6 () at
>> ../../../../../engine/test/test_element_node.cpp:62
>> #18 0x03be6b33 in Catch::TestInvokerAsFunction::invoke
>> (this=0x7326650) at
>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11841
>> #19 0x03be16d6 in Catch::TestCase::invoke (this=0x738eb00) at
>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11742
>> #20 0x03be160a in Catch::RunContext::invokeActiveTestCase
>> (this=0x7fffd7c8) at
>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10601
>> #21 0x03be0164 in Catch::RunContext::runCurrentTest
>> (this=0x7fffd7c8, redirectedCout=..., redirectedCerr=...) at
>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10574
>> #22 0x03bdf4fc in Catch::RunContext::runTest
>> (this=0x7fffd7c8, testCase=...) at
>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10344
>> #23 0x03be39fd in Catch::(anonymous namespace)::runTests
>> (config=...) at
>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10903
>> #24 0x03be34b2 in Catch::Session::runInternal
>> (this=0x7fffdb50) at
>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11098
>> #25 0x03be322b in Catch::Session::run (this=0x7fffdb50) at
>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:11055
>> #26 0x03c1257a in Catch::Session::run (this=0x7fffdb50,
>> argc=1, argv=0x7fffdda8) at
>> ../../../../../.mm/linux/amd64/debug/include/catch2/catch.hpp:10801
>> #27 0x03bf4c58 in main (argc=1, 

Re: [v8-users] Re: V8 compilation without custom libcxx

[Jakob Gruber]

On Tue, Jul 2, 2019 at 2:17 AM Cvetan Stefanovski  wrote:

> Hello,
>
> I have the same problem embedding V8 (7.5.288.23) into my Android
> application. I tried to get rid of that custom libcxx to no avail. Next
> that I want to try is to link my JNI <> V8 bridge library against the same
> libcxx that V8 libs link to.
> Bump. Any of the devs having something to add?
>

I'm not sure what you mean by 'tried to get rid ... to no avail'. The
`use_custom_libcxx = false` flag should disable the custom libcxx and use
the system library instead. Are you running into compile errors? Link
errors? If so, please open a bug for this at crbug.com/v8/new.

See https://crbug.com/v8/9150#c2 for a bit more information on
use_custom_libcxx.


>
> On Tuesday, 18 June 2019 00:54:56 UTC+3, Renato wrote:
>>
>> Hi,
>> I was updating an old V8 app to the latest API but I was having some
>> linker errors (VS2019) related with this call:
>>
>> std::unique_ptr platform = v8::platform::NewDefaultPlatform
>> ()
>>
>> I found that now V8 uses a custom libcxx that I really don't want to
>> propagate to my app so i tried to disable it... without success.
>>
>> My V8 compile settings are:
>>
>> is_debug=false
>> is_component_build = true
>> target_cpu = "x64"
>> v8_enable_i18n_support=false
>> use_lld = false
>> v8_use_external_startup_data = false
>> use_glib=false
>> use_custom_libcxx=false
>> use_prebuilt_instrumented_libraries=false
>> is_clang=false
>> v8_enable_embedded_builtins=false
>> use_locally_built_instrumented_libraries=false
>> v8_use_snapshot=true
>>
>>
>> To be able to get v8.dll, v8_libplatform.dll and v8_libbase.dll not
>> depending of the new custom libcxx I had to checkout the tag 7.5.168
>> none of the next versions works.
>> Is there a new setting that I have to use with the newest tags to compile
>> a v8.dll that doesn't depends on the custom libcxx?
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/d8805ef0-e078-46ad-a7cf-f6b3df4c5fc7%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oPXSudLWOUn2WxSuPbXZKxkk1t7LMephXX6v4FHt6jLjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Reducing V8 binary size in JIT-less mode

[Jakob Gruber]

Hi Darin,

On Mon, Jul 1, 2019 at 2:22 PM Darin Dimitrov 
wrote:

> According to https://v8.dev/blog/jitless, starting from 7.4, V8 supports
> JIT-less mode making it suitable for restricted environments.
>
> My goal is to reduce the binary size by stripping the optimizing compiler
> code which is not needed when running in this mode.
>
> Is any configuration flag which will compile V8 in this *lightweight*
> mode?
>

Unfortunately, right now there is no easy way to conditionally compile out
components (e.g.: TurboFan, wasm, the debugger, etc.). It's certainly
possible to add support though and I see how it could be interesting for
embedders.

I don't think we have concrete plans for this at the moment, but would
welcome contributions.


>
> Right now I am getting both "v8_base_without_compiler" and "v8_compiler"
> but I was not able to link my application without the "v8_compiler" module.
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/0dd1c357-5d83-47cb-b32e-ab3e7e504d07%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oMOdTEJ0Tdf1fYTNkZpz1a6iUoaZ07%3Dx%3DWLmacJYzqYaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Issues cross compiling v8 for iOS

[Jakob Gruber]

A fix is in-flight here: https://crrev.com/c/1631417
<https://crrev.com/c/1631417>

On Mon, May 27, 2019 at 3:35 PM Darin Dimitrov 
wrote:

> Hi Jakob,
>
> Thanks for the quick reply. The following patch seems to resolve the issue
> with the iOS build:
>
> *diff --git a/src/snapshot/embedded/platform-embedded-file-writer-base.cc
> b/src/snapshot/embedded/platform-embedded-file-writer-base.cc*
>
> *index 2adb041371..20af9e28e2 100644*
>
> *--- a/src/snapshot/embedded/platform-embedded-file-writer-base.cc*
>
> *+++ b/src/snapshot/embedded/platform-embedded-file-writer-base.cc*
>
> @@ -62,7 +62,7 @@ EmbeddedTargetArch ToEmbeddedTargetArch(const char* s) {
>
>  EmbeddedTargetOs DefaultEmbeddedTargetOs() {
>
>  #if defined(V8_OS_AIX)
>
>return EmbeddedTargetOs::kAIX;
>
> -#elif defined(V8_OS_MACOSX)
>
> +#elif defined(V8_OS_MACOSX) || defined(V8_OS_IOS)
>
>return EmbeddedTargetOs::kMac;
>
>  #elif defined(V8_OS_WIN)
>
>return EmbeddedTargetOs::kWin;
>
> @@ -83,7 +83,7 @@ EmbeddedTargetOs ToEmbeddedTargetOs(const char* s) {
>
>  return EmbeddedTargetOs::kChromeOS;
>
>} else if (string == "fuchsia") {
>
>  return EmbeddedTargetOs::kFuchsia;
>
> -  } else if (string == "mac") {
>
> +  } else if (string == "mac" || string == "ios") {
>
>  return EmbeddedTargetOs::kMac;
>
>} else if (string == "win") {
>
>  return EmbeddedTargetOs::kWin;
>
>
> On Monday, May 27, 2019 at 2:49:42 PM UTC+3, Jakob Gruber wrote:
>>
>> Hi Darin,
>>
>> I've been reworking cross-compile support in mksnapshot and may
>> have missed the iOS case in OS detection
>> <https://crrev.com/c/1622854/15/src/snapshot/embedded/platform-embedded-file-writer-base.cc>.
>> Let me take a look and get back to you.
>>
>> Jakob
>>
>> On Mon, May 27, 2019 at 1:40 PM Darin Dimitrov 
>> wrote:
>>
>>> I am trying to cross compile V8 for iOS (
>>> https://chromium.googlesource.com/v8/v8.git/+/be47fd1c37ead74cf5c4479043426e0376d3ff29)
>>> as described here: https://v8.dev/docs/cross-compile-ios
>>>
>>> Using Mac OS 10.14.5 and XCode 10.2.1 I am getting the following error
>>> when building *embedded.S*:
>>>
>>> [1321/1328] ASM obj/v8_snapshot/embedded.o
>>> FAILED: obj/v8_snapshot/embedded.o
>>> ../../third_party/llvm-build/Release+Asserts/bin/clang -MMD -MF obj/
>>> v8_snapshot/embedded.o.d -DNO_TCMALLOC -DCHROMIUM_BUILD -
>>> DCR_XCODE_VERSION=1021 -DCR_CLANG_REVISION=\"361212-67510fac-2\"
>>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2
>>> -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
>>> -DNS_BLOCK_ASSERTIONS=1 -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64
>>> -DENABLE_MINOR_MC -DENABLE_HANDLE_ZAPPING -DV8_USE_SNAPSHOT
>>> -DV8_CONCURRENT_MARKING -DV8_EMBEDDED_BUILTINS -DV8_WIN64_UNWINDING_INFO
>>> -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS
>>> -DV8_TARGET_ARCH_X64 -DDISABLE_UNTRUSTED_CODE_MITIGATIONS
>>> -DV8_DEPRECATION_WARNINGS -DV8_IMMINENT_DEPRECATION_WARNINGS -I../.. -Igen
>>> -I../.. -Igen -fno-strict-aliasing --param=ssp-buffer-size=4
>>> -fstack-protector -fcolor-diagnostics -fmerge-all-constants
>>> -fcrash-diagnostics-dir=../../tools/clang/crashreports -Xclang -mllvm
>>> -Xclang -instcombine-lower-dbg-declare=0 -std=c11 -arch x86_64 -g2
>>> -isysroot
>>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator12.2.sdk
>>> -stdlib=libc++ -mios-simulator-version-min=10 -c gen/embedded.S -o
>>> obj/v8_snapshot/embedded.o
>>> gen/embedded.S:68:15: error: unexpected token in '.section' directive
>>> .section .text
>>>   ^
>>> gen/embedded.S:379:1: error: unknown directive
>>> .type Builtins_RecordWrite, @function
>>> ^
>>> gen/embedded.S:431:1: error: unknown directive
>>> .type Builtins_EphemeronKeyBarrier, @function
>>> ^
>>> gen/embedded.S:448:1: error: unknown directive
>>> .type Builtins_AdaptorWithBuiltinExitFrame, @function
>>> ^
>>> gen/embedded.S:453:1: error: unknown directive
>>> .type Builtins_ArgumentsAdaptorTrampoline, @function
>>> ^
>>> gen/embedded.S:466:1: error: unknown directive
>>> .type Builtins_CallFunction_ReceiverIsNullOrUndefined, @function
>>> ^
>>>  and hundreds of other similar errors ...
>>>
>>>
>>> This was working fine

Re: [v8-users] Issues cross compiling v8 for iOS

[Jakob Gruber]

Hi Darin,

I've been reworking cross-compile support in mksnapshot and may have missed
the iOS case in OS detection
.
Let me take a look and get back to you.

Jakob

On Mon, May 27, 2019 at 1:40 PM Darin Dimitrov 
wrote:

> I am trying to cross compile V8 for iOS (
> https://chromium.googlesource.com/v8/v8.git/+/be47fd1c37ead74cf5c4479043426e0376d3ff29)
> as described here: https://v8.dev/docs/cross-compile-ios
>
> Using Mac OS 10.14.5 and XCode 10.2.1 I am getting the following error
> when building *embedded.S*:
>
> [1321/1328] ASM obj/v8_snapshot/embedded.o
> FAILED: obj/v8_snapshot/embedded.o
> ../../third_party/llvm-build/Release+Asserts/bin/clang -MMD -MF obj/
> v8_snapshot/embedded.o.d -DNO_TCMALLOC -DCHROMIUM_BUILD -DCR_XCODE_VERSION
> =1021 -DCR_CLANG_REVISION=\"361212-67510fac-2\" -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -DNDEBUG -DNVALGRIND
> -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DNS_BLOCK_ASSERTIONS=1
> -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64 -DENABLE_MINOR_MC
> -DENABLE_HANDLE_ZAPPING -DV8_USE_SNAPSHOT -DV8_CONCURRENT_MARKING
> -DV8_EMBEDDED_BUILTINS -DV8_WIN64_UNWINDING_INFO -DV8_DEPRECATION_WARNINGS
> -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_TARGET_ARCH_X64
> -DDISABLE_UNTRUSTED_CODE_MITIGATIONS -DV8_DEPRECATION_WARNINGS
> -DV8_IMMINENT_DEPRECATION_WARNINGS -I../.. -Igen -I../.. -Igen
> -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector
> -fcolor-diagnostics -fmerge-all-constants
> -fcrash-diagnostics-dir=../../tools/clang/crashreports -Xclang -mllvm
> -Xclang -instcombine-lower-dbg-declare=0 -std=c11 -arch x86_64 -g2
> -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator12.2.sdk
> -stdlib=libc++ -mios-simulator-version-min=10 -c gen/embedded.S -o
> obj/v8_snapshot/embedded.o
> gen/embedded.S:68:15: error: unexpected token in '.section' directive
> .section .text
>   ^
> gen/embedded.S:379:1: error: unknown directive
> .type Builtins_RecordWrite, @function
> ^
> gen/embedded.S:431:1: error: unknown directive
> .type Builtins_EphemeronKeyBarrier, @function
> ^
> gen/embedded.S:448:1: error: unknown directive
> .type Builtins_AdaptorWithBuiltinExitFrame, @function
> ^
> gen/embedded.S:453:1: error: unknown directive
> .type Builtins_ArgumentsAdaptorTrampoline, @function
> ^
> gen/embedded.S:466:1: error: unknown directive
> .type Builtins_CallFunction_ReceiverIsNullOrUndefined, @function
> ^
>  and hundreds of other similar errors ...
>
>
> This was working fine with this revision:
> https://chromium.googlesource.com/v8/v8.git/+/e0a109c05821fa36ec20e1f25895c23baa8d64c3
>
> --
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/aa630655-4f80-4de3-9392-2d44af42c47f%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAH3p7oOTOuf_%3D2bL3k5Zwq2H%3D%2BU%3DQrao-Njk9Z0Ov2X8PsdRWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Instrumentation with V8

[Jakob Gruber]

On Thu, Feb 28, 2019 at 12:05 PM Ben Noordhuis  wrote:

> On Tue, Feb 26, 2019 at 10:36 PM Harold Camacho 
> wrote:
> > I wanted some help with instrumentation with the v8 engine.
> >
> > I wanted to know if it's possible to inject JavaScript code with V8
> (like a global counter) so that I can count all the functions (even the
> JavaScript core functions) that are executed (and the number of times) when
> I run JavaScript files or a benchmark.
>
> The built-in inspector has code coverage functionality, it's the
> 'Profiler.startPreciseCoverage' command.
>
>
> https://github.com/v8/v8/blob/6d78dbdb7b46b6e2497f7eb1b4570c75a6455a09/src/inspector/js_protocol.pdl#L784-L811


+1, see also the blog post at https://v8.dev/blog/javascript-code-coverage.
This will not explicitly give you built-in function call counts though.

-- 
-- 
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] Error cross compiling V8 with is_component_build=true on ARM64

[Jakob Gruber]

+Michael Achenbach 

On Wed, Feb 20, 2019 at 1:04 PM Darin Dimitrov 
wrote:

> Yes, but there's no *libandroid_support.a* for ARM64. This file exists
> only for ARM and x86 in the NDKs. Also as far as I know, API levels >= 21
> do not need this file anymore.
>
> Looking at this line here:
> https://chromium.googlesource.com/chromium/src/build.git/+/refs/heads/master/config/android/BUILD.gn#120
>
> libs += [ "android_support" ]
>
> It looks like V8 is *always *trying to link to *libandroid_support.a*. If
> I put a condition there:
>
> if (current_cpu != "arm64") {
> libs += [ "android_support" ]
> }
>
> then everything seems to build and work fine.
>
> On Wednesday, February 20, 2019 at 12:20:01 PM UTC+2, Jakob Gruber wrote:
>>
>> You are building with target_os="android"; would you expect this to not
>> need libandroid_support?
>>
>> On Wed, Feb 20, 2019 at 10:23 AM Darin Dimitrov 
>> wrote:
>>
>>> I am trying to cross compile V8 for ARM64 with *is_component_build=true*
>>> for ARM64:
>>>
>>> gn gen outgn/release --args="is_component_build=true is_debug=false
>>> symbol_level=0 target_cpu=\"arm64\" v8_target_cpu=\"arm64\"
>>> target_os=\"android\""
>>> ninja -v -C outgn/release v8_libplatform
>>>
>>> And getting the following compilation error when linking libc++:
>>>
>>> [85/89] python "../../build/toolchain/gcc_solink_wrapper.py" --readelf=
>>> "../../third_party/android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-readelf"
>>> --nm=
>>> "../../third_party/android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-nm"
>>> --strip=../../buildtools/third_party/eu-strip/bin/eu-strip --sofile=
>>> "./lib.unstripped/libc++.cr.so" --tocfile="./libc++.cr.so.TOC" --output=
>>> "./libc++.cr.so" -- ../../third_party/llvm-build/Release+Asserts/bin/
>>> clang++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro
>>> -Wl,-z,defs -Wl,--as-needed --gcc-toolchain=../../third_party/
>>> android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 -
>>> fuse-ld=lld -Wl,-z,max-page-size=4096 -Wl,--icf=all -Wl,--color-diagnostics
>>> -Wl,--no-rosegment -Wl,--exclude-libs=libgcc.a -Wl,--exclude-libs=
>>> libvpx_assembly_arm.a --target=aarch64-linux-android 
>>> -Wl,--warn-shared-textrel
>>> -Wl,-O2 -Wl,--gc-sections --sysroot=../../third_party/android_ndk/
>>> platforms/android-21/arch-arm64 -nostdlib -Wl,--warn-shared-textrel -
>>> Werror -Wl,-u_sanitizer_options_link_helper -L../../third_party/
>>> android_ndk/sources/cxx-stl/llvm-libc++/libs/arm64-v8a -o
>>> "./lib.unstripped/libc++.cr.so" -Wl,-soname="libc++.cr.so" @
>>> "./libc++.cr.so.rsp"
>>> FAILED: libc++.cr.so libc++.cr.so.TOC lib.unstripped/libc++.cr.so
>>> python "../../build/toolchain/gcc_solink_wrapper.py" --readelf=
>>> "../../third_party/android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-readelf"
>>> --nm=
>>> "../../third_party/android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-nm"
>>> --strip=../../buildtools/third_party/eu-strip/bin/eu-strip --sofile=
>>> "./lib.unstripped/libc++.cr.so" --tocfile="./libc++.cr.so.TOC" --output=
>>> "./libc++.cr.so" -- ../../third_party/llvm-build/Release+Asserts/bin/
>>> clang++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro
>>> -Wl,-z,defs -Wl,--as-needed --gcc-toolchain=../../third_party/
>>> android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 -
>>> fuse-ld=lld -Wl,-z,max-page-size=4096 -Wl,--icf=all -Wl,--color-diagnostics
>>> -Wl,--no-rosegment -Wl,--exclude-libs=libgcc.a -Wl,--exclude-libs=
>>> libvpx_assembly_arm.a --target=aarch64-linux-android 
>>> -Wl,--warn-shared-textrel
>>> -Wl,-O2 -Wl,--gc-sections --sysroot=../../third_party/android_ndk/
>>> platforms/android-21/arch-arm64 -nostdlib -Wl,--warn-shared-textrel -
>>> Werror -Wl,-u_sanitizer_options_link_helper -L../../third_party/
>>> android_ndk/sources/cxx-stl/llvm-libc++/libs/arm64-v8a -o
>>> "./lib.unstripped/libc++.cr.so" -Wl,-soname="libc++.cr.so" @
>>> "./libc++.cr.so.rsp"
>>> ld.lld: error: unable to find library -landroid_support
>>>
>>> So the question is why is the linker trying to find *libandroid_supprt*
>>> for ARM64 builds and how to fix this error?
>>>
>>>
>>>
>

-- 
-- 
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] Error cross compiling V8 with is_component_build=true on ARM64

[Jakob Gruber]

You are building with target_os="android"; would you expect this to not
need libandroid_support?

On Wed, Feb 20, 2019 at 10:23 AM Darin Dimitrov 
wrote:

> I am trying to cross compile V8 for ARM64 with *is_component_build=true*
> for ARM64:
>
> gn gen outgn/release --args="is_component_build=true is_debug=false
> symbol_level=0 target_cpu=\"arm64\" v8_target_cpu=\"arm64\"
> target_os=\"android\""
> ninja -v -C outgn/release v8_libplatform
>
> And getting the following compilation error when linking libc++:
>
> [85/89] python "../../build/toolchain/gcc_solink_wrapper.py" --readelf=
> "../../third_party/android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-readelf"
> --nm=
> "../../third_party/android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-nm"
> --strip=../../buildtools/third_party/eu-strip/bin/eu-strip --sofile=
> "./lib.unstripped/libc++.cr.so" --tocfile="./libc++.cr.so.TOC" --output=
> "./libc++.cr.so" -- ../../third_party/llvm-build/Release+Asserts/bin/clang
> ++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl
> ,-z,defs -Wl,--as-needed --gcc-toolchain=../../third_party/android_ndk/
> toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 -fuse-ld=lld -
> Wl,-z,max-page-size=4096 -Wl,--icf=all -Wl,--color-diagnostics 
> -Wl,--no-rosegment
> -Wl,--exclude-libs=libgcc.a -Wl,--exclude-libs=libvpx_assembly_arm.a --
> target=aarch64-linux-android -Wl,--warn-shared-textrel -Wl,-O2 
> -Wl,--gc-sections
> --sysroot=../../third_party/android_ndk/platforms/android-21/arch-arm64 
> -nostdlib
> -Wl,--warn-shared-textrel -Werror -Wl,-u_sanitizer_options_link_helper -L
> ../../third_party/android_ndk/sources/cxx-stl/llvm-libc++/libs/arm64-v8a -o
> "./lib.unstripped/libc++.cr.so" -Wl,-soname="libc++.cr.so" @
> "./libc++.cr.so.rsp"
> FAILED: libc++.cr.so libc++.cr.so.TOC lib.unstripped/libc++.cr.so
> python "../../build/toolchain/gcc_solink_wrapper.py" --readelf=
> "../../third_party/android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-readelf"
> --nm=
> "../../third_party/android_ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/bin/aarch64-linux-android-nm"
> --strip=../../buildtools/third_party/eu-strip/bin/eu-strip --sofile=
> "./lib.unstripped/libc++.cr.so" --tocfile="./libc++.cr.so.TOC" --output=
> "./libc++.cr.so" -- ../../third_party/llvm-build/Release+Asserts/bin/clang
> ++ -shared -Wl,--fatal-warnings -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl
> ,-z,defs -Wl,--as-needed --gcc-toolchain=../../third_party/android_ndk/
> toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 -fuse-ld=lld -
> Wl,-z,max-page-size=4096 -Wl,--icf=all -Wl,--color-diagnostics 
> -Wl,--no-rosegment
> -Wl,--exclude-libs=libgcc.a -Wl,--exclude-libs=libvpx_assembly_arm.a --
> target=aarch64-linux-android -Wl,--warn-shared-textrel -Wl,-O2 
> -Wl,--gc-sections
> --sysroot=../../third_party/android_ndk/platforms/android-21/arch-arm64 
> -nostdlib
> -Wl,--warn-shared-textrel -Werror -Wl,-u_sanitizer_options_link_helper -L
> ../../third_party/android_ndk/sources/cxx-stl/llvm-libc++/libs/arm64-v8a -o
> "./lib.unstripped/libc++.cr.so" -Wl,-soname="libc++.cr.so" @
> "./libc++.cr.so.rsp"
> ld.lld: error: unable to find library -landroid_support
>
> So the question is why is the linker trying to find *libandroid_supprt*
> for ARM64 builds and how to fix this error?
>
>
>

-- 
-- 
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] PSA: Changes to supported V8 build modes

[Jakob Gruber]

*TLDR: we are planning to remove support for nosnapshot builds (gn flag:
'v8_use_snapshot = false') and builds without embedded builtins (gn flag:
'v8_enable_embedded_builtins = false').*

*Snapshot?*
Currently, V8 supports building with- and without a snapshot
. In nosnapshot builds each
isolate is created from scratch while snapshot builds deserialize the
initial heap state from snapshot_blob.bin.

*Embedded builtins?*
V8's builtin code objects used to be part of the initial heap state. With
the recent addition of embedded builtins
, builtin code objects can now be
compiled into the V8 binary instead.

*What will change*
We are planning to
1. remove support for nosnapshot builds, and
2. remove support for builds without embedded builtins (noembed builds).

nosnapshot and noembed builds should be considered deprecated as of V8 7.4.
They are subject to removal in 7.5 onwards.

Embedders will need to update any custom build processes to use embedded
builtins. Specifically, mksnapshot now generates an assembly file (pass
--embedded_src ) that is later compiled into the V8 binary. See V8's
BUILD.gn

file for an example.

Note that mksnapshot must thus run prior to compilation of the V8 binary.
Due to dependencies between the snapshot blob and embedded builtins, it is
strongly recommended to generate both in the same mksnapshot run.

-- 
-- 
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] mksnapshot creates invalid embedded.S on MacOS

[Jakob Gruber]

This

is
where the _ prefixes are generated. Specifically, mksnapshot generates an
embedded.S file based on the host OS, which is incorrect for
cross-compilation. A similar issue came up for OSX-to-Fuchsia
cross-compiles, see https://crrev.com/c/1377230 for the fix. Something
similar should also work for you.

As a more general solution we should dispatch based on the target (instead
of host) OS / architecture in this entire file. Could you file a bug? I'm
also happy to accept patches for this.

On Wed, Feb 6, 2019 at 4:35 PM Darin Dimitrov 
wrote:

> I am trying to cross-compile V8 for ARM on MacOS. At some point of the
> compilation process, mksnapshot is used to create the snapshot_blob.bin
> file:
>
> python ../../tools/run.py ./clang_x86_v8_arm/mksnapshot 
> --turbo_instruction_scheduling
> --embedded_src gen/embedded.S --embedded_variant Default --random-seed
> 314159265 --startup_blob snapshot_blob.bin
>
> The resulting embedded.S seems invalid because all label names are
> prefixed with _
>
> .text
> .balign 32
> _v8_Default_embedded_blob_data_:
>   .octa 0x320030c00d96c5c,0x3a0003803600038
>   
> _Builtins_AdaptorWithExitFrame:
>   .octa 0xe24dd004e1a04080e285e591700f,
> 0xee0eca10e51acfc3e52d3004e92d0012
>   ...
> _Builtins_AdaptorWithBuiltinExitFrame:
>   .octa 0xe24dd004e1a04080e285e591700f,
> 0xee0eca10e51acfc3e52d3004e92d0012
>   ...
> _Builtins_ArgumentsAdaptorTrampoline:
>   .octa 0xe1520a34e152000ce30fcfff,
> 0xe92d4813e3a04024e080ba12
>   ...
>
>
>
> As a result, a compilation error is emitted:
>
> FAILED: obj/v8_external_snapshot/embedded.o
>
> ../../third_party/llvm-build/Release+Asserts/bin/clang -MMD -MF obj/
> v8_external_snapshot/embedded.o.d -DV8_DEPRECATION_WARNINGS -DNO_TCMALLOC
> -DSAFE_BROWSING_DB_REMOTE -DOFFICIAL_BUILD -DCHROMIUM_BUILD 
> -DFIELDTRIAL_TESTING_ENABLED
> -D_GNU_SOURCE -DANDROID -DHAVE_SYS_UIO_H -DANDROID_NDK_VERSION_ROLL=r16_1
> -DCR_CLANG_REVISION=\"346388-5\" -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -D__GNU_SOURCE=1
> -DCHROMIUM_CXX_TWEAK_INLINES -DNDEBUG -DNVALGRIND
> -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DV8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=64
> -DENABLE_MINOR_MC -DV8_DEPRECATION_WARNINGS
> -DV8_IMMINENT_DEPRECATION_WARNINGS -DV8_USE_SNAPSHOT
> -DV8_USE_EXTERNAL_STARTUP_DATA -DV8_CONCURRENT_MARKING
> -DV8_EMBEDDED_BUILTINS -DV8_TARGET_ARCH_ARM -DCAN_USE_ARMV7_INSTRUCTIONS
> -DCAN_USE_VFP3_INSTRUCTIONS -DCAN_USE_VFP32DREGS -DCAN_USE_NEON -I../..
> -Igen -I../.. -Igen -fPIC -fno-strict-aliasing --param=ssp-buffer-size=4
> -fstack-protector -funwind-tables -fPIC -fcolor-diagnostics
> -fmerge-all-constants -Xclang -mllvm -Xclang
> -instcombine-lower-dbg-declare=0 -no-canonical-prefixes -std=c11
> -ffunction-sections -fno-short-enums --target=arm-linux-androideabi
> -isystem../../third_party/android_ndk/sysroot/usr/include/arm-linux-androideabi
> -D__ANDROID_API__=16 -DHAVE_PTHREAD_COND_TIMEDWAIT_MONOTONIC=1
> -march=armv7-a -mfloat-abi=softfp -mtune=generic-armv7-a -mfpu=neon -g0
> --sysroot=../../third_party/android_ndk/sysroot -c gen/embedded.S -o
> obj/v8_external_snapshot/embedded.o
> gen/embedded.S:41481:17: error: unable to emit symbol attribute in
> directive
> .private_extern _v8_Default_embedded_blob_
> ^
> gen/embedded.S:41486:1: error: unknown directive
> .const_data
> ^
> gen/embedded.S:41487:17: error: unable to emit symbol attribute in
> directive
> .private_extern _v8_Default_embedded_blob_size_
> ^
> ninja: build stopped: subcommand failed.
>
>
>
> The same process works fine on Ubuntu where the embedded.S labels are not
> prefixed with underscores.
>
> Do you have any idea where this difference in the generated embedded.S
> might come from?
>
> NOTE: I am building from the 7.2.502.24 tag.
>
>
>

-- 
-- 
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: [blink-dev] Re: [v8-dev] Intent to Ship: RegExp @@matchAll / String.prototype.matchAll

[Jakob Gruber]

LGTM3

On Fri, Dec 14, 2018 at 1:57 AM Adam Klein  wrote:

> LGTM2
>
> On Thu, Dec 13, 2018 at 3:27 PM Sathya Gunasekaran 
> wrote:
>
>> LGTM
>> On Thu, Dec 13, 2018 at 2:01 PM Peter Wong 
>> wrote:
>> >
>> > Contact emails
>> > peter.wm.w...@gmail.com
>> > jgru...@chromium.org
>> > yang...@chromium.org
>> >
>> > math...@chromium.org
>> >
>> >
>> > Spec
>> > https://github.com/tc39/proposal-string-matchall/
>> >
>> > https://tc39.github.io/proposal-string-matchall/
>> >
>> >
>> > Summary
>> > String.prototype.matchAll behaves similarly to String.prototype.match,
>> but returns a full regexp result object for each match in a global or
>> sticky regexp.
>> >
>> > Motivation
>> > This offers a simple way to iterate over matches when access to e.g.
>> capture groups is needed.
>> >
>> > const string = 'Magic hex numbers: DEADBEEF CAFE 8BADF00D';
>> > const regex = /\b[0-9a-fA-F]+\b/g;
>> > for (const match of string.matchAll(regex)) {
>> >  console.log(match);
>> > }
>> >
>> > // Iteration 1:
>> > [
>> >  'DEADBEEF',
>> >  index: 19,
>> >  input: 'Magic hex numbers: DEADBEEF CAFE 8BADF00D'
>> > ]
>> >
>> > // Iteration 2:
>> > [
>> >  'CAFE',
>> >  index: 28,
>> >  input: 'Magic hex numbers: DEADBEEF CAFE 8BADF00D'
>> > ]
>> >
>> > // Iteration 3:
>> > [
>> >  '8BADF00D',
>> >  index: 33,
>> >  input: 'Magic hex numbers: DEADBEEF CAFE 8BADF00D'
>> > ]
>> >
>> >
>> > Interoperability risk
>> > Firefox: In development -
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1435829
>> > Edge: No public signals
>> > Safari: No public signals -
>> https://bugs.webkit.org/show_bug.cgi?id=186694
>> > Web developers: Positive
>> >
>> > Compatibility risk
>> > The spec has undergone a few updates and depending on whether other
>> implementations have kept up, there is a possibility V8 could differ in
>> behavior.  At the time of writing, V8 is current with all the latest spec
>> updates and have contributed updates to the test262 test suite to minimize
>> difference between other implementations.
>> >
>> >
>> > V8 tests (mjsunit) as well as all test262 tests pass for this feature.
>> >
>> > Will this feature be supported on all six Blink platforms (Windows,
>> Mac, Linux,
>> > Chrome OS, Android, and Android WebView)?
>> >
>> > Yes
>> >
>> > Link to entry on the Chrome Platform Status
>> > https://www.chromestatus.com/features/5520028858318848
>> >
>> > Requesting approval to ship?
>> > Yes. Note that since this is a V8/JS feature, this post is just an FYI
>> to blink-dev — no signoff from Blink API owners is required.
>> >
>> >
>> > --
>> > --
>> > v8-dev mailing list
>> > v8-...@googlegroups.com
>> > http://groups.google.com/group/v8-dev
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups "v8-dev" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to v8-dev+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMd%2BM7zTAcnN5Aqwr1XdpBfd45Het_nOq2%3Deu6U_TvTRRDtVOQ%40mail.gmail.com
>> .
>>
>>

-- 
-- 
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: Heap snapshot crash on ARM in V8 7.1.302.28

[Jakob Gruber]

I can repro the CHECK failure on master, opened https://crbug.com/v8/8572.

On Mon, Dec 10, 2018 at 2:13 PM Darin Dimitrov 
wrote:

> Strangely enough, if I create a large number of strings just after
> creating the isolate, everything works fine:
>
> for (int i = 0; i < 70; i++) {
> v8::String::NewFromUtf8(isolate, "aaa");
> }
>
>
>
>
> On Wednesday, December 5, 2018 at 6:46:41 PM UTC+2, Darin Dimitrov wrote:
>>
>> Hello,
>>
>> We are embedding v8 in android on an ARM device and trying to load a heap
>> snapshot generated with the mksnapshot utility:
>>
>> ./outgn/arm-release/clang_x86_v8_arm/mksnapshot ./test.js --startup_blob
>> ./snapshot.blob --profile_deserialization
>>
>> And we are getting the following crash at runtime:
>>
>> SIGSEGV (signal SIGSEGV: address access protected (fault address:
>> 0x34ff4d81))
>>
>>
>> v8::internal::SafepointEntry::HasRegisters() const 0xa148f03a
>> v8::internal::StandardFrame::IterateCompiledFrame(v8::internal::
>> RootVisitor*) const 0xa130a394
>> v8::internal::Isolate::Iterate(v8::internal::RootVisitor*, v8::internal::
>> ThreadLocalTop*) 0xa1342510
>> v8::internal::Heap::IterateStrongRoots(v8::internal::RootVisitor*, v8::
>> internal::VisitMode) 0xa131c132
>> v8::internal::MarkCompactCollector::MarkRoots(v8::internal::RootVisitor*,
>> v8::internal::ObjectVisitor*) 0xa1384ade
>> v8::internal::MarkCompactCollector::MarkLiveObjects() 0xa1382c7a
>> v8::internal::MarkCompactCollector::CollectGarbage() 0xa13828e0
>> v8::internal::Heap::MarkCompact() 0xa1317ffe
>> v8::internal::Heap::PerformGarbageCollection(v8::internal::
>> GarbageCollector, v8::GCCallbackFlags) 0xa13169e6
>> v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::
>> internal::GarbageCollectionReason, v8::GCCallbackFlags)
>> 0xa13159b2
>> v8::internal::Heap::AllocateRawWithLightRetry(int, v8::internal::
>> AllocationSpace, v8::internal::AllocationAlignment) 0xa131cfca
>> v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::
>> AllocationSpace, v8::internal::AllocationAlignment) 0xa131d018
>> v8::internal::Factory::NewFeedbackVector(v8::internal::Handle> internal::SharedFunctionInfo>, v8::internal::PretenureFlag)
>> 0xa12f4ccc
>> v8::internal::FeedbackVector::New(v8::internal::Isolate*, v8::internal::
>> Handle) 0xa1303564
>> v8::internal::JSFunction::EnsureFeedbackVector(v8::internal::Handle> internal::JSFunction>) 0xa13d4862
>> v8::internal::Compiler::Compile(v8::internal::Handle> JSFunction>, v8::internal::Compiler::ClearExceptionFlag)
>> 0xa12965d2
>> v8::internal::Runtime_CompileLazy(int, v8::internal::Object**, v8::
>> internal::Isolate*) 0xa16d9f16
>> Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit
>> 0xa17c9db0
>> Builtins_CompileLazy 0xa17288fc
>>  0x4658d4b8
>>  0x4658d4b8
>>  0x4658d4b8
>>  0x4658d4b8
>> Builtins_JSEntryTrampoline 0xa1725668
>>  0x46586d54
>>
>> Unfortunately this stacktrace doesn't originate from our code which makes
>> it very hard to debug. This error only happens with V8 7.1.302.28, the
>> snapshot worked pretty smooth in 6.9.427.23.
>>
>> Do you have any idea what might be causing this crash or any pointers
>> that could help us further diagnose it?
>>
>> Note: V8 is compiled with the following flags:
>>
>> gn gen outgn/arm-release --args="v8_use_snapshot=true
>> v8_use_external_startup_data=false is_official_build=true is_debug=false
>> symbol_level=0 use_thin_lto=false target_cpu=\"arm\" v8_target_cpu=\"arm\"
>> v8_enable_i18n_support=false target_os=\"android\"
>> v8_android_log_stdout=false"
>>
>> ninja -C outgn/arm-release v8_base v8_libplatform v8_libbase
>> v8_libsampler v8_snapshot v8_initializers v8_init inspector
>>
>>

-- 
-- 
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] Heap snapshot crash on ARM in V8 7.1.302.28

[Jakob Gruber]

Something is wrong in frame iteration.. Is the crash reproducible? Have you
checked if it happens on the current V8 version?

Please open a bug at https://crbug.com/v8/new and include the script you
are embedding if possible.

On Wed, Dec 5, 2018 at 5:46 PM Darin Dimitrov 
wrote:

> Hello,
>
> We are embedding v8 in android on an ARM device and trying to load a heap
> snapshot generated with the mksnapshot utility:
>
> ./outgn/arm-release/clang_x86_v8_arm/mksnapshot ./test.js --startup_blob
> ./snapshot.blob --profile_deserialization
>
> And we are getting the following crash at runtime:
>
> SIGSEGV (signal SIGSEGV: address access protected (fault address:
> 0x34ff4d81))
>
>
> v8::internal::SafepointEntry::HasRegisters() const 0xa148f03a
> v8::internal::StandardFrame::IterateCompiledFrame(v8::internal::
> RootVisitor*) const 0xa130a394
> v8::internal::Isolate::Iterate(v8::internal::RootVisitor*, v8::internal::
> ThreadLocalTop*) 0xa1342510
> v8::internal::Heap::IterateStrongRoots(v8::internal::RootVisitor*, v8::
> internal::VisitMode) 0xa131c132
> v8::internal::MarkCompactCollector::MarkRoots(v8::internal::RootVisitor*,
> v8::internal::ObjectVisitor*) 0xa1384ade
> v8::internal::MarkCompactCollector::MarkLiveObjects() 0xa1382c7a
> v8::internal::MarkCompactCollector::CollectGarbage() 0xa13828e0
> v8::internal::Heap::MarkCompact() 0xa1317ffe
> v8::internal::Heap::PerformGarbageCollection(v8::internal::
> GarbageCollector, v8::GCCallbackFlags) 0xa13169e6
> v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::
> internal::GarbageCollectionReason, v8::GCCallbackFlags) 0xa13159b2
> v8::internal::Heap::AllocateRawWithLightRetry(int, v8::internal::
> AllocationSpace, v8::internal::AllocationAlignment) 0xa131cfca
> v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::
> AllocationSpace, v8::internal::AllocationAlignment) 0xa131d018
> v8::internal::Factory::NewFeedbackVector(v8::internal::Handle ::SharedFunctionInfo>, v8::internal::PretenureFlag) 0xa12f4ccc
> v8::internal::FeedbackVector::New(v8::internal::Isolate*, v8::internal::
> Handle) 0xa1303564
> v8::internal::JSFunction::EnsureFeedbackVector(v8::internal::Handle internal::JSFunction>) 0xa13d4862
> v8::internal::Compiler::Compile(v8::internal::Handle JSFunction>, v8::internal::Compiler::ClearExceptionFlag)
> 0xa12965d2
> v8::internal::Runtime_CompileLazy(int, v8::internal::Object**, v8::
> internal::Isolate*) 0xa16d9f16
> Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit
> 0xa17c9db0
> Builtins_CompileLazy 0xa17288fc
>  0x4658d4b8
>  0x4658d4b8
>  0x4658d4b8
>  0x4658d4b8
> Builtins_JSEntryTrampoline 0xa1725668
>  0x46586d54
>
> Unfortunately this stacktrace doesn't originate from our code which makes
> it very hard to debug. This error only happens with V8 7.1.302.28, the
> snapshot worked pretty smooth in 6.9.427.23.
>
> Do you have any idea what might be causing this crash or any pointers that
> could help us further diagnose it?
>
> Note: V8 is compiled with the following flags:
>
> gn gen outgn/arm-release --args="v8_use_snapshot=true
> v8_use_external_startup_data=false is_official_build=true is_debug=false
> symbol_level=0 use_thin_lto=false target_cpu=\"arm\" v8_target_cpu=\"arm\"
> v8_enable_i18n_support=false target_os=\"android\"
> v8_android_log_stdout=false"
>
> ninja -C outgn/arm-release v8_base v8_libplatform v8_libbase
> v8_libsampler v8_snapshot v8_initializers v8_init inspector
>
>
>
> --
> --
> 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] Crash in mksnapshot

[Jakob Gruber]

I'd suggest opening a bug at https://crbug.com/v8/new. Ideally provide
exact error output, gn args, repro instructions, and details about the
machine you're using.

On Tue, Nov 27, 2018 at 4:45 PM madana gopal 
wrote:

> Hi Team,
>
> Please provide suggestions towards above crash. Will it be due to any
> endianess or 32-bit related etc. Whether we might have missed any
> initializations?.
>
> 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] Crash in mksnapshot

[Jakob Gruber]

Try a debug build and run mksnapshot in gdb. You'll get a meaningful stack
trace there. Have you tried updating to a more recent V8 version?

On Mon, Nov 26, 2018 at 2:51 PM madana gopal 
wrote:

> Hi Team,
>
> I am facing below crash when building V8 (version 6.9.351) for mipsel
> platform.
>
> FAILED: gen/embedded.cc snapshot_blob.bin
> python ../../tools/run.py ./mksnapshot --turbo_instruction_scheduling
> --embedded_src gen/embedded.cc --embedded_variant Default --random-seed
> 314159265 --startup_blob snapshot_blob.bin
>
>
> #
> # Fatal error in , line 0
> # Check failed: args[2]->IsSmi().
> #
> #
> #
> #FailureMessage Object: 0x7654f554
>  C stack trace ===
>
> ./mksnapshot(+0x877b08) [0x76dc9b08]
> ./mksnapshot(+0x739ce4) [0x76c8bce4]
> ./mksnapshot(+0x735500) [0x76c87500]
> ./mksnapshot(+0x398374) [0x768ea374]
> [0x5d888c50]
> qemu: unhandled CPU exception 0x16 - aborting
> pc=0x76c8a490 HI=0x LO=0x ds 00e2 76c8a464 1
>
>
> Any thoughts? Please provide some suggestion.
>
> 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] Access violation when constructing a new isolate: invalid builtins?

[Jakob Gruber]

Could you open a new bug at crbug.com/v8/new and include minimal repro?

On Mon, Sep 3, 2018 at 6:13 PM, Dickson Tan 
wrote:

> Hi,
>
> I'm getting errors when creating a new context, and it crashes with an
> access violation here on api.cc:
>
>   // Sanity-check that the isolate is initialized and usable.
>
>   CHECK(isolate->builtins()->builtin(i::Builtins::kIllegal)->IsCode());
>
> Which eventually calls line 142 of builtins.cc:
>
> Code* Builtins::builtin(int index) { return isolate_->heap()->builtin(index);
> }
>

Just to be clear, what exactly is crashing? Is the CHECK expectation
failing or something before that?


>
> I'm building with MSVC on windows 10 x64, with the following build flags
>
> is_debug = true
> target_cpu = "x64"
> is_component_build = false
> v8_static_library = true
> v8_enable_i18n_support=false
> is_clang=false
> use_lld = false
> v8_use_snapshot=false
>
> At first, I thought that somehow its not finding my snapshots even though
> its in the correct location, but this occurs even when compiling without
> snapshot support.
>
> I've also done all initialization as per the hello world example, and am
> building against v7.1.0 (pulled from git a few days ago).
>
> Appreciate any help - 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] Public API to check validity of a snapshot?

[Jakob Gruber]

On Thu, Aug 23, 2018 at 5:32 PM, Ian Ker-Seymer  wrote:

> Hey there!
>
> I am working on a project which embeds v8 and uses snapshots. We are
> calling v8 from ruby, and would like to be able to check whether or not a
> snapshot is valid (meaning it was created by a matching version of v8).
> Currently, `CheckVersion` will fatally abort, but we would like to be able
> to check the version and raise an error which can be recovered from. Is
> there a public API for this? If not, how could we go about doing this
> without relying on too many v8 internals?
>
>
>
As far as I know we currently don't have an API for this, but it seems like
a meaningful use case to support. I could imagine e.g. adding an IsValid
method to StartupData
.
+Yang, any thoughts?

I opened https://crbug.com/v8/8104 to track this.

-- 
-- 
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] Debugger acting as a client connecting to the server

['Jakob Gruber' via v8-users]

+yang who can say more about node.

We (Ben, Yang & myself) recently discussed the possibility of adding
coverage support to node itself. See here

for a (very rough and early stage) doc with some thoughts.

On Wed, Aug 8, 2018 at 10:22 PM, demurgos  wrote:

> Hi,
> I work on Node.js code coverage tools using V8's profiler (c8).
>
> There are currently 2 methods to use the V8 debug protocol from Node.
> 1. You can spawn a process with the  `--inspect` or `--inspect-brk` flag.
> This starts V8 in "server mode" and remote clients can connect to it and
> interact with the debugger.
> 2. You can use Node's "inspector" module to enable a process to debug
> itself (communicate with its own V8)
>
> This means to profile a V8 runtime, you need to first start the V8 process
> and then connect the inspector to it.
>
> This system causes a mismatch with the needs of coverage. nyc (istanbul)
> and c8 want to get coverage for all the node processes spawned in a process
> sub-tree.
> We have a single top process collecting coverage and each Node subprocess
> reports its results to it.
>
> This means that we have the opposite system: the inspector is started
> first, and then many debugged processes connect to it.
> But this is not supported by V8.
> So we use a "brutal hack" called "spawn-wrap".
>
> It intercepts all the Node processes created in a subtree and replaces its
> main module by another one. This wrapper module has the logic to start the
> profiler, execute the original entry point and then report the results.
>
> This solution is far from optimal. The wrapping mechanism is complex and
> hard to maintain, if the entry point forces the process to close
> immediately the reporting code is not executed, and the execution of the
> wrapper entry-point can interfere with the the coverage.
>
> Some of these issues can be solved, but the mismatch remains: we have to
> engineer a level on top of the V8 debugger because the connection can only
> go in one direction currently: the inspector connects to the debugger.
>
> I would like to know what it would take to support the opposite scenario:
> start an inspector server on some port (ex 9333) and then ask the debugger
> to initiate the connection.
> It would act like:
>
> inspectorServer.on("connection", (client) => {console.log("New connection"
> );})
> await inspectorServer.start();
> spawn("node", ["foo.js"], {env: {NODE_OPTIONS="--inspect-srv=9333"}});
>
> Ensuring that all the subprocesses have the same env var or flag is easier
> to achieve than hijacking the entry-point to emulate this kind of feature.
>
> I believe that this kind of feature needs to be implemented in V8. Am I
> right? Should I redirect this feature request to Node? Is it the right
> place to post this message?
>

-- 
-- 
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] what is the relationship between natives_blob.bin and snapshot_blob.bin?

[Jakob Gruber]

On Tue, Jul 17, 2018 at 11:55 AM,  wrote:

> Thanks for your kindly reply.
>
> What do you mean "Js natives"? Are they some c++ native functions written
> in c++ on which v8's build-in js source codes depend?
>

JS natives are builtin code shipped with V8 that are still implemented in
JavaScript, see e.g.:
https://cs.chromium.org/chromium/src/v8/src/js/array.js?l=1=f1b3e80faad6c84deabec8043bae524d1480293b


>
> I noticed that "v8_use_external_startup_data" is only used when "
> v8_use_snapshot=true". So I thought "v8_use_external_startup_data" just
> controls whether snapshot data is compiled into the binary. But actually it
> controls both snapshot data and natives_blob data.
>
> Given "v8_use_snapshot=true v8_use_external_startup_data=false", I can
> find the equivalent of snapshot_blob.bin that is snapshot.cc generated by
> mksnapshot, but I can't find the  equivalent of native_blob.bin.
>

The equivalent for natives_blob.bin is libraries.cc
<https://cs.chromium.org/chromium/src/out/Debug/gen/v8/libraries.cc>.


>
> Also I thought "v8_use_snapshot" is used to control the disable/enable of
> snapshot functionality, but actually it controls the generation of default
> snapshot data. Even if given "v8_use_snapshot=false", I can still feed v8
> with my custom snapshot data.
>

Right. Look for V8_USE_SNAPSHOT in the V8 source code to see what changes
(spoiler: not much). It's mostly the build process
<https://cs.chromium.org/chromium/src/BUILD.gn?rcl=1de71b638f99c15a3f97ec7b25b0c6dc920fbee0>
that differs.


>
> 在 2018年7月17日星期二 UTC+8下午3:31:11，Jakob Gruber写道：
>>
>> natives_blob.bin contains the minified source code of JS natives shipped
>> with V8, while snapshot_blob.bin contains the startup and context
>> snapshots. We are working on removing natives_blob.bin, hopefully this will
>> happen sometime this year.
>>
>> Given "v8_use_snapshot=true v8_use_external_startup_data=false", the
>> serialized data is compiled into the binary.
>> Given "v8_use_snapshot=true v8_use_external_startup_data=true",
>> serialized data is shipped as the external .bin files you mentioned.
>>
>> I hope that helps a bit. I'm not sure I understand your remaining
>> questions, could you clarify if things are still unclear?
>>
>> On Thu, Jul 12, 2018 at 10:52 AM,  wrote:
>>
>>> when v8 is compiled with options "v8_use_snapshot=true
>>> v8_use_external_startup_data=true", two files which are
>>> natives_blob.bin  and snapshot_blob.bin will be generated. when we use v8
>>> in our embedder progroam, *V8::InitializeExternalStartupData *need be
>>> called to load the two files. After that, we need to new a isolate by
>>> calling *Isolate::New* that will call
>>> *isolate->set_snapshot_blob(i::Snapshot::DefaultSnapshotBlob());* if we
>>> don't supply a custom snapshot data by specifing *CreateParams*'s snaps
>>> hot_blob.
>>>
>>> But if v8 is complied with options "v8_use_snapshot=true
>>> v8_use_external_startup_data=false",  natives_blob.bin  and
>>> snapshot_blob.bin will not be generated. *V8::InitializeExternalStartupData
>>> *need not be called. Can I call *Isolate::New *with a custom snapshot
>>> data that was generated by *SnapshotCreator *Api. Notice in this case
>>> no natives_blob.bin is supplied. So is natives_blob.bin necessary ? Is
>>> natives_blob.bin complied into v8 binary?
>>>
>>> we can still supply a custom snapshot to *CreateParams even i*f v8 is
>>> complied with options "v8_use_snapshot=false", is that right?
>>>
>>> what is the relationship between natives_blob.bin and snapshot_blob.bin?
>>> why not just generate one snapshot file?
>>>
>>>

-- 
-- 
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] How to off DCHECK?

[Jakob Gruber]

Edit the DCHECK macro definition:
https://cs.chromium.org/chromium/src/v8/src/base/logging.h?l=63=f1b3e80faad6c84deabec8043bae524d1480293b

On Tue, Jul 17, 2018 at 11:37 AM,  wrote:

> I am using d8 in debug mode.
> I would like to disable the dcheck functions in this state. Do I have any
> compile options like this?
>

-- 
-- 
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] what is the relationship between natives_blob.bin and snapshot_blob.bin?

[Jakob Gruber]

natives_blob.bin contains the minified source code of JS natives shipped
with V8, while snapshot_blob.bin contains the startup and context
snapshots. We are working on removing natives_blob.bin, hopefully this will
happen sometime this year.

Given "v8_use_snapshot=true v8_use_external_startup_data=false", the
serialized data is compiled into the binary.
Given "v8_use_snapshot=true v8_use_external_startup_data=true", serialized
data is shipped as the external .bin files you mentioned.

I hope that helps a bit. I'm not sure I understand your remaining
questions, could you clarify if things are still unclear?

On Thu, Jul 12, 2018 at 10:52 AM,  wrote:

> when v8 is compiled with options "v8_use_snapshot=true
> v8_use_external_startup_data=true", two files which are natives_blob.bin
> and snapshot_blob.bin will be generated. when we use v8 in our embedder
> progroam, *V8::InitializeExternalStartupData *need be called to load the
> two files. After that, we need to new a isolate by calling *Isolate::New*
> that will call
> *isolate->set_snapshot_blob(i::Snapshot::DefaultSnapshotBlob());* if we
> don't supply a custom snapshot data by specifing *CreateParams*'s
> snapshot_blob.
>
> But if v8 is complied with options "v8_use_snapshot=true
> v8_use_external_startup_data=false",  natives_blob.bin  and
> snapshot_blob.bin will not be generated. *V8::InitializeExternalStartupData
> *need not be called. Can I call *Isolate::New *with a custom snapshot
> data that was generated by *SnapshotCreator *Api. Notice in this case no
> natives_blob.bin is supplied. So is natives_blob.bin necessary ? Is
> natives_blob.bin complied into v8 binary?
>
> we can still supply a custom snapshot to *CreateParams even i*f v8 is
> complied with options "v8_use_snapshot=false", is that right?
>
> what is the relationship between natives_blob.bin and snapshot_blob.bin?
> why not just generate one snapshot file?
>
>
>

-- 
-- 
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: Performance drop?

[Jakob Gruber]

Interesting, I'm not aware of anything specific that slows down
Context::New. Could you perhaps narrow down the regression further & file a
bug? The build flags below look fine to me.

On Tue, Jul 17, 2018 at 1:14 AM, jzw  wrote:

> I narrowed down to context creation time.
> when I measure the time around v8::Context::New(), I noticed 30%-40%
> increase with the newer version. This is with snapshot enabled. I am
> wondering if I could further reduce the time for context creation or have
> to accept it?
> Thank you!
>
>
> On Friday, July 13, 2018 at 5:47:53 PM UTC-7, jzw wrote:
>>
>> Hello,
>> We recently upgraded v8 from 5.3 to 6.7. And when doing a profiling test
>> after embedding, I found the speed with the new build is slower than the
>> old one(quite significant). I know there is fair chance that our old way of
>> embedding v8 causes inefficiency. Apart from that, may I get some
>> suggestions to make the build faster (for release at least).
>>
>> Currently I compiled v8 with the following options
>> is_debug = false
>> is_official_build = true
>> is_component_build = true
>> is_cfi = false
>> is_clang = false
>> use_custom_libcxx = false
>> use_sysroot = false
>>
>> is the build with the above options already most optimized one? Any more
>> options I could use?
>>
>

-- 
-- 
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] OOM in Heap::ReserveSpace

['Jakob Gruber' via v8-users]

Even without a repro, could you open a bug? It's easier to loop in people
and discuss there. Thanks!

On Sat, Jul 7, 2018 at 2:43 AM, Yvonne Chen  wrote:

> Actually, not mprotect. madvise, in ReclaimInaccessibleMemory, with both
> MADV_FREE and MADV_DONTNEED calls failing, both with error code EINVAL.
>
> On Friday, July 6, 2018 at 4:44:00 PM UTC-7, Yvonne Chen wrote:
>>
>> Still unable to produce a standalone repo, but I've narrowed down the
>> issue - eventually, a call to mprotect fails with error code EINVAL, while
>> trying to create a pre-code guard page.
>> Probably means there's some system level configuration we have that's not
>> playing well with v8?
>>
>> On Thursday, July 5, 2018 at 3:27:48 PM UTC-7, Yvonne Chen wrote:
>>>
>>> It's the case where "if (allocation.To(_space))" is false.
>>>
>>> I'm currently unable to reproduce this outside of our main codebase into
>>> a standalone test file, but I'll file a bug if I manage to do so.
>>>
>>> On Wednesday, July 4, 2018 at 12:05:30 AM UTC-7, Jakob Gruber wrote:
>>>>
>>>> Could you check which 'perform_gc = true' case we reach? See
>>>>
>>>> https://cs.chromium.org/chromium/src/v8/src/heap/heap.cc?l=
>>>> 1614=fe51067f43e7208d06977d5036726360a4539d7b
>>>>
>>>> Then please open a bug at http://crbug.com/v8/new.
>>>>
>>>> On Wed, Jul 4, 2018 at 12:18 AM, Yvonne Chen  wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm in the process of trying to upgrade from v8 6.0.186 to 6.7.288.46.
>>>>> In heap.cc, the latter now has a check for !deserialization_complete_
>>>>> before throwing an OOM error. For some reason, my code can create one
>>>>> Isolate just fine, but if I try to create another, I run into the error.
>>>>> The comments in heap.cc suggest a low max old space size as a possible
>>>>> reason, but my code uses all defaults for heap initial values and
>>>>> everything worked fine on the previous v8 version, so that seems unlikely
>>>>> to be the culprit. What other possible cases could result in
>>>>> deserialization_complete_ being false at this point? Or maybe perform_gc 
>>>>> is
>>>>> getting set when it's not supposed to be?
>>>>>
>>>>> Stack trace, not sure if it helps much though:
>>>>>
>>>>> <--- Last few GCs --->
>>>>>
>>>>>
>>>>> <--- JS stacktrace --->
>>>>>
>>>>>
>>>>> #
>>>>> # Fatal process OOM in insufficient memory to create an Isolate
>>>>> #
>>>>>
>>>>>
>>>>> Thread 12 "threadname" received signal SIGILL, Illegal instruction.
>>>>> [Switching to Thread 0x748eb700 (LWP 2646)]
>>>>> v8::base::OS::Abort () at ../../src/base/platform/platfo
>>>>> rm-posix.cc:381
>>>>> 381 V8_IMMEDIATE_CRASH();
>>>>> (gdb) bt
>>>>> #0  v8::base::OS::Abort () at ../../src/base/platform/platfo
>>>>> rm-posix.cc:381
>>>>> #1  0x007bb68a in v8::Utils::ReportOOMFailure ()
>>>>> at ../../src/api.cc:432
>>>>> #2  0x007bb887 in v8::internal::V8::FatalProcessOutOfMemory ()
>>>>> at ../../src/api.cc:400
>>>>> #3  0x0097231c in v8::internal::Heap::ReserveSpace ()
>>>>> at ../../src/heap/heap.cc:1611
>>>>> #4  0x00ee7914 in 
>>>>> v8::internal::DefaultDeserializerAllocator::ReserveSpace
>>>>> () at ../../src/snapshot/default-deserializer-allocator.cc:177
>>>>> #5  0x00b87e93 in 
>>>>> v8::internal::StartupDeserializer::DeserializeInto
>>>>> ()
>>>>> at ../../src/snapshot/startup-deserializer.cc:21
>>>>> #6  0x009f8593 in v8::internal::Isolate::Init ()
>>>>> at ../../src/isolate.cc:3068
>>>>> #7  0x00b87958 in v8::internal::Snapshot::Initialize ()
>>>>> at ../../src/snapshot/snapshot-common.cc:54
>>>>> #8  0x007d1208 in v8::IsolateNewImpl () at
>>>>> ../../src/api.cc:8367
>>>>>
>>>>>
>>>>> --
> --
> 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] OOM in Heap::ReserveSpace

[Jakob Gruber]

Could you check which 'perform_gc = true' case we reach? See

https://cs.chromium.org/chromium/src/v8/src/heap/heap.cc?l=1614=fe51067f43e7208d06977d5036726360a4539d7b

Then please open a bug at http://crbug.com/v8/new.

On Wed, Jul 4, 2018 at 12:18 AM, Yvonne Chen  wrote:

> Hi,
>
> I'm in the process of trying to upgrade from v8 6.0.186 to 6.7.288.46. In
> heap.cc, the latter now has a check for !deserialization_complete_ before
> throwing an OOM error. For some reason, my code can create one Isolate just
> fine, but if I try to create another, I run into the error. The comments in
> heap.cc suggest a low max old space size as a possible reason, but my code
> uses all defaults for heap initial values and everything worked fine on the
> previous v8 version, so that seems unlikely to be the culprit. What other
> possible cases could result in deserialization_complete_ being false at
> this point? Or maybe perform_gc is getting set when it's not supposed to be?
>
> Stack trace, not sure if it helps much though:
>
> <--- Last few GCs --->
>
>
> <--- JS stacktrace --->
>
>
> #
> # Fatal process OOM in insufficient memory to create an Isolate
> #
>
>
> Thread 12 "threadname" received signal SIGILL, Illegal instruction.
> [Switching to Thread 0x748eb700 (LWP 2646)]
> v8::base::OS::Abort () at ../../src/base/platform/platform-posix.cc:381
> 381 V8_IMMEDIATE_CRASH();
> (gdb) bt
> #0  v8::base::OS::Abort () at ../../src/base/platform/
> platform-posix.cc:381
> #1  0x007bb68a in v8::Utils::ReportOOMFailure ()
> at ../../src/api.cc:432
> #2  0x007bb887 in v8::internal::V8::FatalProcessOutOfMemory ()
> at ../../src/api.cc:400
> #3  0x0097231c in v8::internal::Heap::ReserveSpace ()
> at ../../src/heap/heap.cc:1611
> #4  0x00ee7914 in 
> v8::internal::DefaultDeserializerAllocator::ReserveSpace
> () at ../../src/snapshot/default-deserializer-allocator.cc:177
> #5  0x00b87e93 in v8::internal::StartupDeserializer::DeserializeInto
> ()
> at ../../src/snapshot/startup-deserializer.cc:21
> #6  0x009f8593 in v8::internal::Isolate::Init ()
> at ../../src/isolate.cc:3068
> #7  0x00b87958 in v8::internal::Snapshot::Initialize ()
> at ../../src/snapshot/snapshot-common.cc:54
> #8  0x007d1208 in v8::IsolateNewImpl () at ../../src/api.cc:8367
>
>
>

-- 
-- 
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 V8 on Windows with Visual Studio 2017

[Jakob Gruber]

See https://github.com/v8/v8/wiki/Using-Git. Since something seems messed
up with your gclient install (which will fetch clang-cl.exe), try the steps
in 'How to start' for a clean checkout. Hope that helps.

On Tue, Jul 3, 2018 at 8:52 PM, Mike Moening  wrote:

> Oh and I've tried running: *gclient sync *from my v8 directory:
>
> C:\Dev\common\v8>gclient sync
> C:\Dev\common\.gclient_entries missing, .gclient file in parent directory
> C:\Dev\common might not be the file you want to use.
>
> and it doesn't seem to bring down *third_party/llvm-build*
> Should it??
> What am I missing?
>

-- 
-- 
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] Find out the bytecode associated with given JIT code?

[Jakob Gruber]

Take a look at v8's gdbinit file for more convenience macros:
https://cs.chromium.org/chromium/src/v8/tools/gdbinit

On Tue, Jun 19, 2018 at 12:48 AM, Caitlin Potter  wrote:

> Print_Code will output information for any Code object (builtins, bytecode
> handlers, JIT-ed code, even IC stubs AFAIU) — so it should already do that
> for you.
>
> The main limitation WRT optimized code is, if some part of the fn is
> inlined, it won’t tell you anything about the code that was inlined/where
> it came from (I think)
>
>
> On Jun 18, 2018, at 5:04 PM, Thomson Tan  wrote:
>
> Thanks. This works perfectly for bytecode handlers. Is there any similar
> function for optimized JIT code, like print out the function name with some
> extra information?
>
>

-- 
-- 
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] kKeep segfault

[Jakob Gruber]

Do you perhaps have a backtrace? Please open a bug at
http://crbug.com/v8/new and assign it to me, I'll take a look.

On Mon, Jun 18, 2018 at 3:15 PM, Ryan Dahl  wrote:

> Hi,
>
> I'm experiencing a segfault when using 
> SnapshotCreator::FunctionCodeHandling::kKeep.
> I'm wondering if this is intended behavior or a bug?
>
> Here is a patch to demo it in test/cctest/test-serialize.cc
> https://gist.github.com/ry/0429eb4887370ee2a263446a59ec9ed7
>
> thank you,
> Ryan
>
>
>

-- 
-- 
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] compile problem of v8_use_external_startup_data

[Jakob Gruber]

Look for occurrences of 'v8_use_external_startup_data' in BUILD.gn (
https://cs.chromium.org/chromium/src/v8/BUILD.gn?l=265=739f5abc518dbe94bf245ae60d3b95e377290123).
My guess is that your error is related to the V8_USE_EXTERNAL_STARTUP_DATA
define.

You can also print the full compilation command used by ninja with the -v
flag:

$ ninja  -v

On Fri, Jun 8, 2018 at 10:21 AM, czczcheng  wrote:

> I set the options v8_use_external_startup_data=false
> try to run the sample hello-world  with out the file snapshot_blob.bin
> it's ok when i use ninja to compile
> but if i use g++ directly it failed
> #
> # Fatal error in , line 0
> # Check failed: (i_isolate->snapshot_blob()) == nullptr.
> #
> #
> #
> #FailureMessage Object: 0x7ffd769487f0
>  C stack trace ===
>
> ./hello-world(+0xaa4ef6) [0x7f64a37bbef6]
> ./hello-world(+0x942f0b) [0x7f64a3659f0b]
> ./hello-world(+0x93898b) [0x7f64a364f98b]
> ./hello-world(+0xdfcfb) [0x7f64a2df6cfb]
> ./hello-world(+0xdfd2a) [0x7f64a2df6d2a]
> ./hello-world(+0xc64a1) [0x7f64a2ddd4a1]
> /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f64a190cb35]
> ./hello-world(+0xc62dd) [0x7f64a2ddd2dd]
>
> I try to debug the program, find the code src/api.cc:8260
> i_isolate->set_snapshot_blob(i::Snapshot::DefaultSnapshotBlob());
> in the good program generated by ninja, the DefaultSnapshotBlob return a
> section of data, length is 1329232
> but in the bad program generated by g++, the DefaultSnapshotBlob return a
> section of data, length is zero
>
> DefaultSnapshotBlob was defined in src/snapshot/snapshot-empty.cc and just
> return nullptr
> there is another file: out.gn/release.x64/gen/snapshot.cc the function
> was defined again,
> i guess the defination in snapshot.cc is the real function to call , but
> why it could return anything when i use g++ to compile binary?
> can anyone help me?
>

-- 
-- 
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] How to cache a compiled module?

[Jakob Gruber]

Not yet, but we're working on it. See: https://crbug.com/v8/7685

On Mon, May 7, 2018 at 2:54 PM, czczcheng  wrote:

> i want to cache a compiled module, and serialize it to disk , is there any
> method?
>
> --
> --
> 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] Building in linux, either v8_libplatform and v8_libbase are all I get, or they're the only things that are missing!

['Jakob Gruber' via v8-users]

Did you see https://github.com/v8/v8/wiki/Building-from-Source? To build
all targets, just use:

$ ninja -C out.gn/golib/

On Fri, Apr 20, 2018 at 7:25 AM, Andrew Walker  wrote:

> I am attempting to build v8 in a wheezy VM for a binding that links
> against
>
>- libv8
>- v8_base
>- v8_init
>- v8_initializers
>- v8_libbase
>- v8_libplatform
>- v8_libsampler
>- v8_nosnapshot
>
> But when I build the x64 .release target, all I get is:
>
> # ./tools/dev/v8gen.py x64.release
> # ninja -C out.gn/x64.release/ v8_libbase v8_libplatform v8_base
> v8_nosnapshot v8_libsampler v8_init v8_initializers
> # ls -l out.gn/x64.release/obj/*.a
> out.gn/x64.release/obj/libv8_libbase.a
> out.gn/x64.release/obj/libv8_libplatform.a
>
>
>
> Trying the following from the  I get:
> # gn gen out.gn/golib --args="strip_debug_info=true
> v8_use_external_startup_data=false v8_enable_i18n_support=false
> v8_enable_gdbjit=false v8_static_library=true symbol_level=0
> target_cpu=\"x64\"
> # ninja -C out.gn/golib/ v8_libbase v8_libplatform v8_base v8_nosnapshot
> v8_libsampler v8_init v8_initializers
> # ls -l out.gn/golib/obj/*.a
> out.gn/golib/obj/libv8_base.a
> out.gn/golib/obj/libv8_libsampler.a
> out.gn/golib/obj/libv8_init.a
> out.gn/golib/obj/libv8_nosnapshot.a
> out.gn/golib/obj/libv8_initializers.a
>
>
> This is incredibly frustrating. Can anyone help me out?
>
> --
> --
> 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] What is the memory layout of a code object in V8?

['Jakob Gruber' via v8-users]

Have a look at [0], which describes the memory layout of code objects. The
RelocInfo is currently a separate object and Code objects store a pointer
to it.

[0]
https://cs.chromium.org/chromium/src/v8/src/objects/code.h?l=369=ff6b34b468c1eae8589b278923f87e2f573bc248

On Thu, Apr 19, 2018 at 11:57 PM, Mingwei Zhang <mingwayzh...@gmail.com>
wrote:

> Hi,
>
> I used gdb with the gdbinit script provided by V8. So I used the command
> called "jco" with an argument of a JIT code address. So I have two
> questions listed below:
>
> 1) what is the header of each JIT code function?
> 2) where is the RelocInfo located for each JIT code function?
>
>
>
> For 1), I find that before the real code content, there is data structure
> in size of 0x60 bytes as I use gdb command to see:
>
> 0x2d88b5f04300: 0x0ccaef902889 0x2a97d2182a09
> 0x2d88b5f04310: 0x2a97d2182241 0x2a97d2182241
> 0x2d88b5f04320: 0x2a97d2182619 0x0804
> 0x2d88b5f04330: 0x2a97d21822d1 0x00060147
> 0x2d88b5f04340: 0x0001 0x
> 0x2d88b5f04350: 0x 0x
>
> Looks like the above byte pattern already exist prior to each code chunk.
>
> 0x2d88b5f04301: [Code]
> kind = STUB
> major_key = CEntryStub
> compiler = unknown
> Instructions (size = 327)
> 0x2d88b5f04360 0  55 push rbp
> 0x2d88b5f04361 1  4889e5 REX.W movq rbp,rsp
> 0x2d88b5f04364 4  6a06   push 0x6
> 0x2d88b5f04366 6  6a00   push 0x0
> 0x2d88b5f04368 8  49ba0143f0b5882d REX.W movq r10,0x2d88b5f04301
>   ;; object: 0x2d88b5f04301 
> 0x2d88b5f0437212  4152   push r10
> ..
> RelocInfo (size = 29)
> 0x2d88b5f0436a  embedded object  (0x2d88b5f04301 )
> 0x2d88b5f04379  external reference (Isolate::c_entry_fp_address)
> (0x42a21a8)
> 0x2d88b5f04386  external reference (Isolate::context_address)  (0x42a2138)
> 0x2d88b5f04393  external reference (Isolate::c_function_address)
> (0x42a21b8)
> ..
>
> For 2), looks like the above info does not exist in JIT code page.
>
> 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.
>

Jakob Gruber

Software Engineer

jgru...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.


This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.

-- 
-- 
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] mksnapshot and warm_up

['Jakob Gruber' via v8-users]

AFAIK that's correct. The polluted warmup context is thrown out, and a
second clean context (with the now-compiled code) is serialized into the
warmed up snapshot.

On Thu, Mar 1, 2018 at 5:31 PM, Johannes Rieken <johannes.rie...@gmail.com>
wrote:

> Great! Thanks for the speedy reply. Looking at https://cs.chromium.org/
> chromium/src/v8/test/cctest/test-serialize.cc?type=cs=
> CustomSnapshotDataBlobWithWarmup=1167 makes me think/hope  that
> functions are being compiled but state isn't changed (e.g. the assignment
> to `a` isn't persistent). Is that a correct assumption?
>
> On Thursday, March 1, 2018 at 5:16:37 PM UTC+1, Jakob Gruber wrote:
>>
>> On Thu, Mar 1, 2018 at 4:43 PM, Johannes Rieken <johanne...@gmail.com>
>> wrote:
>>
>>>
>>> Hey,
>>>
>>> Can someone help me understand what the difference between a warm and
>>> cold snapshot is? I stumbled over `WarmUpSnapshotDataBlob` but I am not
>>> entirely sure how to make use of them via the mksnapshot-tools and what the
>>> sequence would be. Do I begin with a custom snapshot and then snapshot that
>>> snapshot again after its functions have been used?
>>>
>>>
>> Yes. See https://cs.chromium.org/chromium/src/v8/src/snapshot/mks
>> napshot.cc?l=177=fd158bc49d646d93a59cd07d07dfb9627bc94a30 for an
>> example.
>>
>> The steps are also nicely explained here:
>> https://cs.chromium.org/chromium/src/v8/src/api.cc?l=830;
>> rcl=fd158bc49d646d93a59cd07d07dfb9627bc94a30
>>
> --
> --
> 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.
>

Jakob Gruber

Software Engineer

jgru...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.


This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.

-- 
-- 
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] mksnapshot and warm_up

['Jakob Gruber' via v8-users]

On Thu, Mar 1, 2018 at 4:43 PM, Johannes Rieken 
wrote:

>
> Hey,
>
> Can someone help me understand what the difference between a warm and cold
> snapshot is? I stumbled over `WarmUpSnapshotDataBlob` but I am not
> entirely sure how to make use of them via the mksnapshot-tools and what the
> sequence would be. Do I begin with a custom snapshot and then snapshot that
> snapshot again after its functions have been used?
>
>
Yes. See
https://cs.chromium.org/chromium/src/v8/src/snapshot/mksnapshot.cc?l=177=fd158bc49d646d93a59cd07d07dfb9627bc94a30
for an example.

The steps are also nicely explained here:
https://cs.chromium.org/chromium/src/v8/src/api.cc?l=830=fd158bc49d646d93a59cd07d07dfb9627bc94a30

-- 
-- 
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] Lazy deserialization

['Jakob Gruber' via v8-users]

On Fri, Feb 16, 2018 at 5:09 PM, Chris Dumoulin <crdum...@gmail.com> wrote:

> Thanks for the reply Jakob. I'll give your code changes a try.
> I'm currently trying this on Mac OS X x64.
>
> I'm pretty sure I'm using a snapshot build. Is there an easy way to tell
> for sure?
>

Snapshot builds are the default if you're building with gn (it's the
`v8_use_snapshot` flag).
You can always verify by moving snapshot_blob.bin and running
v8_hello_world, which should now crash.


> Do you have any idea why Massif wouldn't show a memory decrease?
>

Sorry, I'm not familiar with Massif and how it measures memory usage. It'd
be interesting to find out more though.


> How was the memory measured for the blog post on lazy deserialization?
>

The reported numbers are from this counter:
memory:chrome:renderer_processes:reported_by_chrome:v8:heap:effective_size

See e.g.:
https://chromeperf.appspot.com/report?sid=5a61019415f14d0e08769209248a634be258c1a6b740fbe876911dd13b6d8731

The blog post shows the difference in this counter after sites with &
without lazy deserialization.


>
> On Friday, 16 February 2018 03:49:24 UTC-5, Jakob Gruber wrote:
>
>> On Thu, Feb 15, 2018 at 9:28 PM, Chris Dumoulin <crdu...@gmail.com>
>> wrote:
>>
>>> I'm interested in minimizing v8 memory usage, and I recently saw this
>>> blog post on Lazy Deserialization: https://v8pro
>>> ject.blogspot.ca/2018/02/lazy-deserialization.html
>>>
>>> I've built and run samples/hello-world.cc against static libraries built
>>> from v6.3 and v6.5, and measured the memory usage using Valgrind's Massif
>>> tool.
>>> I expect to see a reduction in memory usage with v6.5 (due to the lazy
>>> deserialization), but I don't. Is there something I need to do in the code
>>> to enable the lazy deserialization?
>>>
>>
>> Are you sure you're using a snapshot build? If so, lazy deserialization
>> should be enabled by default. What architecture / OS?
>>
>> Locally (Linux x64), I see these numbers:
>>
>> $ out/release/v8_hello_world --no-lazy-deserialization
>> --no-lazy-handler-deserialization --trace-gc
>> Hello, World!
>> name, size, size of objects
>> new_space, 23408, 23408
>> old_space, 820176, 437832
>> code_space, 1039904, 1039904
>> map_space, 525904, 40400
>> large_object_space, 0, 0
>>
>> $ out/release/v8_hello_world --trace-gc
>> Hello, World!
>> name, size, size of objects
>> new_space, 23408, 23408
>> old_space, 820176, 437832
>> code_space, 898208, 396448
>> map_space, 525904, 40400
>> large_object_space, 0, 0
>>
>> Note the difference in code_space. The 'size' column shows the total size
>> of the space, 'size of objects' shows the portion that is actually
>> used/allocated.
>> From a quick look, Massif also didn't show a difference for me.
>>
>> By the way, since you're looking into memory reductions,
>> isolate-independent builtins (doc <http://goo.gl/Z2HUiM>) might also be
>> of interest.
>>
>> Here's the patch to reproduce my numbers above:
>>
>> diff --git a/samples/hello-world.cc b/samples/hello-world.cc
>> index ab6f0dd8bf..d9257d79e9 100644
>> --- a/samples/hello-world.cc
>> +++ b/samples/hello-world.cc
>> @@ -16,6 +16,7 @@ int main(int argc, char* argv[]) {
>>std::unique_ptr platform = v8::platform::NewDefaultPlatfo
>> rm();
>>v8::V8::InitializePlatform(platform.get());
>>v8::V8::Initialize();
>> +  v8::V8::SetFlagsFromCommandLine(, argv, true);
>>
>>// Create a new Isolate and make it the current one.
>>v8::Isolate::CreateParams create_params;
>> diff --git a/src/isolate.cc b/src/isolate.cc
>> index 30f67e3233..b85bf18179 100644
>> --- a/src/isolate.cc
>> +++ b/src/isolate.cc
>> @@ -2629,6 +2629,13 @@ void Isolate::Deinit() {
>>
>>DumpAndResetStats();
>>
>> +  printf("name, size, size of objects\n");
>> +  for (int i = FIRST_SPACE; i <= LAST_SPACE; i++) {
>> +Space* s = heap_.space(i);
>> +printf("%s, %zu, %zu\n", heap_.GetSpaceName(i), s->Size(),
>> +       s->SizeOfObjects());
>> +  }
>> +
>>if (FLAG_print_deopt_stress) {
>>  PrintF(stdout, "=== Stress deopt counter: %u\n",
>> stress_deopt_count_);
>>}
>>
> --
> --
> 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 a

Re: [v8-users] Lazy deserialization

['Jakob Gruber' via v8-users]

On Thu, Feb 15, 2018 at 9:28 PM, Chris Dumoulin  wrote:

> I'm interested in minimizing v8 memory usage, and I recently saw this blog
> post on Lazy Deserialization: https://v8project.blogspot.ca/2018/02/
> lazy-deserialization.html
>
> I've built and run samples/hello-world.cc against static libraries built
> from v6.3 and v6.5, and measured the memory usage using Valgrind's Massif
> tool.
> I expect to see a reduction in memory usage with v6.5 (due to the lazy
> deserialization), but I don't. Is there something I need to do in the code
> to enable the lazy deserialization?
>

Are you sure you're using a snapshot build? If so, lazy deserialization
should be enabled by default. What architecture / OS?

Locally (Linux x64), I see these numbers:

$ out/release/v8_hello_world --no-lazy-deserialization
--no-lazy-handler-deserialization --trace-gc
Hello, World!
name, size, size of objects
new_space, 23408, 23408
old_space, 820176, 437832
code_space, 1039904, 1039904
map_space, 525904, 40400
large_object_space, 0, 0

$ out/release/v8_hello_world --trace-gc
Hello, World!
name, size, size of objects
new_space, 23408, 23408
old_space, 820176, 437832
code_space, 898208, 396448
map_space, 525904, 40400
large_object_space, 0, 0

Note the difference in code_space. The 'size' column shows the total size
of the space, 'size of objects' shows the portion that is actually
used/allocated.
>From a quick look, Massif also didn't show a difference for me.

By the way, since you're looking into memory reductions,
isolate-independent builtins (doc ) might also be of
interest.

Here's the patch to reproduce my numbers above:

diff --git a/samples/hello-world.cc b/samples/hello-world.cc
index ab6f0dd8bf..d9257d79e9 100644
--- a/samples/hello-world.cc
+++ b/samples/hello-world.cc
@@ -16,6 +16,7 @@ int main(int argc, char* argv[]) {
   std::unique_ptr platform =
v8::platform::NewDefaultPlatform();
   v8::V8::InitializePlatform(platform.get());
   v8::V8::Initialize();
+  v8::V8::SetFlagsFromCommandLine(, argv, true);

   // Create a new Isolate and make it the current one.
   v8::Isolate::CreateParams create_params;
diff --git a/src/isolate.cc b/src/isolate.cc
index 30f67e3233..b85bf18179 100644
--- a/src/isolate.cc
+++ b/src/isolate.cc
@@ -2629,6 +2629,13 @@ void Isolate::Deinit() {

   DumpAndResetStats();

+  printf("name, size, size of objects\n");
+  for (int i = FIRST_SPACE; i <= LAST_SPACE; i++) {
+Space* s = heap_.space(i);
+printf("%s, %zu, %zu\n", heap_.GetSpaceName(i), s->Size(),
+   s->SizeOfObjects());
+  }
+
   if (FLAG_print_deopt_stress) {
 PrintF(stdout, "=== Stress deopt counter: %u\n", stress_deopt_count_);
   }

-- 
-- 
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] Advice for submitting a PR to fix Debug::ArchiveDebug and Debug::RestoreDebug?

['Jakob Gruber' via v8-users]

On Mon, Dec 18, 2017 at 9:39 PM, Ben Noordhuis  wrote:

> On Mon, Dec 18, 2017 at 9:06 PM, Ben Newman  wrote:
> > Hi folks! This is my first time posting here, so please let me know if I
> > should ask this question somewhere else instead. I'm asking here because
> > https://github.com/v8/v8 does not have GitHub issues enabled.
> >
> > In short, I have a project that embeds V8 and uses a single `Isolate`
> from
> > multiple threads.
> >
> > The program runs just fine, but sometimes the inspector doesn't stop on
> the
> > correct line after stepping over a statement that switches threads behind
> > the scenes, even though the original thread is restored by the time the
> next
> > statement is executed.
> >
> > From what I can tell, the key information that controls this behavior is
> > `thread_local_.target_frame_count_`, first set here, and then checked
> here.
> >
> > That check fails because `target_frame_count === -1`, which suggests it
> has
> > not been updated since it was last initialized here.
> >
> > Digging a bit deeper, I realized that the `Debug::ArchiveDebug` and
> > `Debug::RestoreDebug` methods, which should be responsible for
> > saving/restoring this `ThreadLocal` information when switching threads,
> > currently don't do anything.
> >
> > I can understand that throwing away debugger state when switching threads
> > might be OK if no one needs to debug a multi-threaded V8 program, but I
> > think I've found a legitimate use case for preserving that state, so I
> would
> > like to submit a PR to fix this.
> >
> > The essence of the PR would be:
> >
> > char* Debug::ArchiveDebug(char* storage) {
> >   MemCopy(storage, reinterpret_cast(_local_),
> > ArchiveSpacePerThread());
> >   return storage + ArchiveSpacePerThread();
> > }
> >
> >
> > char* Debug::RestoreDebug(char* storage) {
> >   MemCopy(reinterpret_cast(_local_), storage,
> > ArchiveSpacePerThread());
> >   return storage + ArchiveSpacePerThread();
> > }
> >
> >
> > int Debug::ArchiveSpacePerThread() {
> >   return sizeof(ThreadLocal);
> > }
> >
> > Would this be a welcome PR? Is there anyone in particular I should ask to
> > review this? Any other advice for a first-time contributor?
> >
> > Thanks,
> > Ben
>
> If it's an obvious bug, then sure, send a CL.  Preferably include a
> regression test in test/cctest.
>
> As to picking a reviewer: git-cl (from depot_tools) can do that for
> you but I personally find its suggestions less than helpful.  I
> usually pick someone from the `git shortlog -ns` top 3 for the files I
> touch (which quite often turns out to be Yang Guo - either we have the
> same interests or he is a commit cannon.)
>
> Note that V8 doesn't use GitHub pull requests.  The process is
> explained here: https://github.com/v8/v8/wiki/Contributing
>

Right, please submit a CL. Mainly yangguo@ will be interested in this, but
feel free to add jgruber@ as reviewer as well.

It's a known issue that debug infos aren't restored when switching threads.
I don't have too much background information on this, maybe Yang will chime
in with more.

-- 
-- 
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] Query regarding file size of snaphot_blob.bin

['Jakob Gruber' via v8-users]

On Tue, Dec 19, 2017 at 7:25 AM, <uzair.jal...@samsung.com> wrote:

> Hi Jakob,
>
> We were comparing v8/src/builtins.h file of Chromium M47 and Chromium M56
> and found that there many new (>100) builtin functions added in Chromium 56.
>
> Do you think this could be one of the major reasons for increase in size
> of Snapshot_blob.bin file ?
>

Yes I assume that's where most of the growth comes from. To verify, you can
print stats about snapshot contents with

out/release/mksnapshot --serialization_statistics

And builtin sizes with (doesn't exist yet in 47):

out/release/mksnapshot --print-builtin-size


>
> Thanks
>
> On Monday, December 18, 2017 at 12:54:34 PM UTC+5:30, Jakob Gruber wrote:
>>
>> On Mon, Dec 18, 2017 at 6:20 AM, <uzair@samsung.com> wrote:
>>
>>> >* new functionality (both internal and new language additions);
>>>
>>> Is it possible to find out what new functionality has been added?(
>>> If yes please can you let me know where to check for new features added ?)
>>>
>>
>> For new language features, you could watch https://github.com/tc39/
>> proposals to track TC39 proposal status. New V8 developments are
>> sometimes called out on the V8 blog, but the only way to get a complete
>> picture is to follow the git commit log.
>>
>>
>>>
>>> Thanks
>>>
>>> On Thursday, December 14, 2017 at 3:24:36 PM UTC+5:30, Jakob Gruber
>>> wrote:
>>>
>>>> On Thu, Dec 14, 2017 at 10:39 AM, <uzair@samsung.com> wrote:
>>>>
>>>>> On Thursday, December 14, 2017 at 2:44:15 PM UTC+5:30, Ben Noordhuis
>>>>> wrote:
>>>>>>
>>>>>> On Thu, Dec 14, 2017 at 7:22 AM,  <uzair@samsung.com> wrote:
>>>>>> > 1) How is snapshot_blob.bin generated at compile time ? (If
>>>>>> possible where
>>>>>> > in chromium code )
>>>>>>
>>>>>> Look for a file called mksnapshot.cc in v8/src/snapshot.
>>>>>>
>>>>>> > 2) Is it possible to reduce the size of snapshot_blob.bin ? (if yes
>>>>>> where in
>>>>>> > chromium code do we do it and will it have any performance
>>>>>> regression ?)
>>>>>>
>>>>>> You could disable internationalization (v8_enable_i18n_support=0) but
>>>>>> that's about it.  It won't affect performance but the Intl JS object
>>>>>> will have only bare-bones functionality.
>>>>>>
>>>>>> You can disable the snapshot entirely (v8_use_snapshot=0) but that
>>>>>> does have a performance impact because it shifts the cost of
>>>>>> construction to Context::New().  Expect that function to slow down by
>>>>>> 5-10x.
>>>>>>
>>>>>
>>>>> Hi Ben,
>>>>>
>>>>> Thanks for the reply :)
>>>>>
>>>>> We disabled  v8_enable_i18n_support and size of snapshot_blob.bin has
>>>>> reduced by 20KB.
>>>>>
>>>>> But is there any way to find out the reason for increase ?
>>>>>
>>>>
>>>> There's a bunch of reasons, but mainly:
>>>>
>>>> * new functionality (both internal and new language additions);
>>>> * and the increasing use of CodeStubAssembler
>>>> <https://v8project.blogspot.de/2017/11/csa.html> to write shipped code
>>>> (vs. implementing builtins
>>>>   as self-hosted JS, shipping the source files and compiling at
>>>> runtime).
>>>>
>>>> > Our current aim is to reduce the size of binary.
>>>>
>>>> I suppose this is the binary in decompressed form, and not something
>>>> like an APK? It'd theoretically
>>>> be possible to support loading from compressed snapshot blobs (for
>>>> roughly 1MB savings), but this
>>>> is not implemented currently.
>>>>
>>> --
>>> --
>>> 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.
>>>
>>
&g

Re: [v8-users] Query regarding file size of snaphot_blob.bin

['Jakob Gruber' via v8-users]

On Mon, Dec 18, 2017 at 6:20 AM, <uzair.jal...@samsung.com> wrote:

> >* new functionality (both internal and new language additions);
>
> Is it possible to find out what new functionality has been added?( If
> yes please can you let me know where to check for new features added ?)
>

For new language features, you could watch https://github.com/tc39/proposals
to track TC39 proposal status. New V8 developments are sometimes called out
on the V8 blog, but the only way to get a complete picture is to follow the
git commit log.


>
> Thanks
>
> On Thursday, December 14, 2017 at 3:24:36 PM UTC+5:30, Jakob Gruber wrote:
>
>> On Thu, Dec 14, 2017 at 10:39 AM, <uzair@samsung.com> wrote:
>>
>>> On Thursday, December 14, 2017 at 2:44:15 PM UTC+5:30, Ben Noordhuis
>>> wrote:
>>>>
>>>> On Thu, Dec 14, 2017 at 7:22 AM,  <uzair@samsung.com> wrote:
>>>> > 1) How is snapshot_blob.bin generated at compile time ? (If possible
>>>> where
>>>> > in chromium code )
>>>>
>>>> Look for a file called mksnapshot.cc in v8/src/snapshot.
>>>>
>>>> > 2) Is it possible to reduce the size of snapshot_blob.bin ? (if yes
>>>> where in
>>>> > chromium code do we do it and will it have any performance regression
>>>> ?)
>>>>
>>>> You could disable internationalization (v8_enable_i18n_support=0) but
>>>> that's about it.  It won't affect performance but the Intl JS object
>>>> will have only bare-bones functionality.
>>>>
>>>> You can disable the snapshot entirely (v8_use_snapshot=0) but that
>>>> does have a performance impact because it shifts the cost of
>>>> construction to Context::New().  Expect that function to slow down by
>>>> 5-10x.
>>>>
>>>
>>> Hi Ben,
>>>
>>> Thanks for the reply :)
>>>
>>> We disabled  v8_enable_i18n_support and size of snapshot_blob.bin has
>>> reduced by 20KB.
>>>
>>> But is there any way to find out the reason for increase ?
>>>
>>
>> There's a bunch of reasons, but mainly:
>>
>> * new functionality (both internal and new language additions);
>> * and the increasing use of CodeStubAssembler
>> <https://v8project.blogspot.de/2017/11/csa.html> to write shipped code
>> (vs. implementing builtins
>>   as self-hosted JS, shipping the source files and compiling at runtime).
>>
>> > Our current aim is to reduce the size of binary.
>>
>> I suppose this is the binary in decompressed form, and not something like
>> an APK? It'd theoretically
>> be possible to support loading from compressed snapshot blobs (for
>> roughly 1MB savings), but this
>> is not implemented currently.
>>
> --
> --
> 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.
>

Jakob Gruber

Software Engineer

jgru...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten
haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter,
löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen,
dass die E-Mail an die falsche Person gesendet wurde.


This e-mail is confidential. If you received this communication by mistake,
please don't forward it to anyone else, please erase all copies and
attachments, and please let me know that it has gone to the wrong person.

-- 
-- 
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] Query regarding file size of snaphot_blob.bin

['Jakob Gruber' via v8-users]

On Thu, Dec 14, 2017 at 10:39 AM,  wrote:

> On Thursday, December 14, 2017 at 2:44:15 PM UTC+5:30, Ben Noordhuis wrote:
>>
>> On Thu, Dec 14, 2017 at 7:22 AM,   wrote:
>> > 1) How is snapshot_blob.bin generated at compile time ? (If possible
>> where
>> > in chromium code )
>>
>> Look for a file called mksnapshot.cc in v8/src/snapshot.
>>
>> > 2) Is it possible to reduce the size of snapshot_blob.bin ? (if yes
>> where in
>> > chromium code do we do it and will it have any performance regression
>> ?)
>>
>> You could disable internationalization (v8_enable_i18n_support=0) but
>> that's about it.  It won't affect performance but the Intl JS object
>> will have only bare-bones functionality.
>>
>> You can disable the snapshot entirely (v8_use_snapshot=0) but that
>> does have a performance impact because it shifts the cost of
>> construction to Context::New().  Expect that function to slow down by
>> 5-10x.
>>
>
> Hi Ben,
>
> Thanks for the reply :)
>
> We disabled  v8_enable_i18n_support and size of snapshot_blob.bin has
> reduced by 20KB.
>
> But is there any way to find out the reason for increase ?
>

There's a bunch of reasons, but mainly:

* new functionality (both internal and new language additions);
* and the increasing use of CodeStubAssembler
 to write shipped code (vs.
implementing builtins
  as self-hosted JS, shipping the source files and compiling at runtime).

> Our current aim is to reduce the size of binary.

I suppose this is the binary in decompressed form, and not something like
an APK? It'd theoretically
be possible to support loading from compressed snapshot blobs (for roughly
1MB savings), but this
is not implemented currently.

-- 
-- 
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] Query regarding file size of snaphot_blob.bin

['Jakob Gruber' via v8-users]

We've actually been working on reducing memory overhead around the snapshot,
see the lazy builtins design doc at http://goo.gl/dxkYDZ. Note though that
this is
intended to reduce runtime memory use, not the size of the snapshot blob
itself. I'd
expect the snapshot blob to grow further in the future.

As Ben says below, it's possible to build V8 without a snapshot, but
startup costs will
increase significantly.

May I ask what your main concern is? Runtime memory consumption or binary
size?

On Thu, Dec 14, 2017 at 10:14 AM, Ben Noordhuis  wrote:

> On Thu, Dec 14, 2017 at 7:22 AM,   wrote:
> > 1) How is snapshot_blob.bin generated at compile time ? (If possible
> where
> > in chromium code )
>
> Look for a file called mksnapshot.cc in v8/src/snapshot.
>
> > 2) Is it possible to reduce the size of snapshot_blob.bin ? (if yes
> where in
> > chromium code do we do it and will it have any performance regression ?)
>
> You could disable internationalization (v8_enable_i18n_support=0) but
> that's about it.  It won't affect performance but the Intl JS object
> will have only bare-bones functionality.
>
> You can disable the snapshot entirely (v8_use_snapshot=0) but that
> does have a performance impact because it shifts the cost of
> construction to Context::New().  Expect that function to slow down by
> 5-10x.

-- 
-- 
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] PSA: Removing NativeWeakMap

[Jakob Gruber]

NativeWeakMap [0] was introduced back in 2015 for DevTools [1], but has
remained unused since then (at least to our knowledge).

If you rely on NativeWeakMap, please speak up now. Otherwise, if no
objections are raised NativeWeakMap will be removed in the near future [2].

[0]
https://cs.chromium.org/chromium/src/v8/include/v8.h?l=2092=f91116b5220f3e4a5cbe0904b3d70f4176f70182
[1] https://crrev.com/900123003
[2] https://crbug.com/v8/7016

-- 
-- 
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] How to compile V8 for X86_64 platform?

['Jakob Gruber' via v8-users]

Hi Sameer,

the V8 build process is documented at
https://github.com/v8/v8/wiki/Building-with-GN.

Cheers,
Jakob

On Wed, Jul 5, 2017 at 7:20 AM, Sameer  wrote:

> Hi,
>
> I am new to V8 world.
> Could you please help how do I compile V8 for X86_64 platforms?
> I am trying to debug some Java scripts and kinda stuck in the middle and
> need to debug further.
>
> Thanks,
> Sameer
>
> --
> --
> 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] Re: Significant JSON::Stringify, Uint8Array, or ArrayBuffer changes between v5.4 to v6.0.186

['Jakob Gruber' via v8-users]

Interesting. It'd be very helpful if you could open a bug at
crbug.com/v8/new with a full code example (including build instructions if
it includes C++) and instructions to reproduce the issue. Feel free to
assign it to me (jgru...@chromium.org) and I'll have a look.

On Mon, Jun 26, 2017 at 6:44 PM, muscovy  wrote:

> In UTF-8, calling JSON.stringify() on the buffer contents:
>
> Old version: \\�u�\"~JM@\u0015'7�`��\u001a]G�MA�\u001fJ�.�
> New version: \\���u�\"~JM@\u0015'7�`��\u001a]G�MA�\u001fJ�.�
>
> However, in both versions, calling String(x) on each array element
> produces the same output:
>
> [0]:92
> [1]:137
> [2]:242
> [3]:152
> [4]:138
> [5]:251
> [6]:117
> [7]:216
> [8]:34
> [9]:126
> [10]:74
> [11]:77
> [12]:64
> [13]:21
> [14]:39
> [15]:55
> [16]:165
> [17]:96
> [18]:135
> [19]:197
> [20]:26
> [21]:93
> [22]:71
> [23]:134
> [24]:77
> [25]:65
> [26]:230
> [27]:31
> [28]:74
> [29]:184
> [30]:46
> [31]:141
>
>
> On Friday, June 23, 2017 at 5:15:01 PM UTC-7, Zac Hansen wrote:
>>
>> can you provide some examples of outputs that have changed?
>>
>> On Friday, June 23, 2017 at 3:35:09 PM UTC-7, muscovy wrote:
>>>
>>> I have a custom buffer-like object whose contents are handed by an
>>> ArrayBuffer:
>>>
>>> Local buf = obj.As()->Buffer();
>>> *data = static_cast(buf->GetContents().Data());
>>>
>>> I also have a js file that uses it, with lines like:
>>>
>>> String(data.length)
>>> JSON.stringify(data)
>>>
>>> This is called over a few hundred objects.
>>>
>>> After upgrading from v8 version 5.4ish to 6.0.186, it seems that for a
>>> handful of objects, obj.length is 1-2 smaller than before, and the output
>>> of JSON.stringify(obj) is also shorter by that amount (the missing bytes
>>> come from anywhere in the buffer).
>>>
>>> Based on what's happening, I think some change in Uint8Array,
>>> ArrayBuffer, or possibly JSON::Stringify could be related, but I
>>> haven't had any luck so far trying to figure it out. Anyone able to point
>>> me in the right direction? 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 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] Upcoming debugger API changes

[Jakob Gruber]

We are planning changes to V8's debugger API in the near- to midterm.

In summary, the JSON API and direct access to the debugger context will be
deprecated and eventually removed in favor of the V8 inspector protocol.

Further details in the design document:

https://docs.google.com/document/d/1M8DdgDldglYjQJ1mu0yBzwgR6lCX-ZKS_hxAJiCLT34/edit?usp=sharing

Jakob

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