Re: [v8-dev] Is Multiple 'EmbedderHeapTracer's Feasible?

[Jochen Eisinger]

I guess what I'm saying is not that you should use gin, but that we
shouldn't change chromium to support multiple tracers, as I don't want to
have to support code that doesn't go through gin

On Fri, Jun 15, 2018 at 7:35 AM Michael Lippautz 
wrote:

> I am OOO until beginning of July now.
>
> Overall, I think we can add that to v8, although I think it would still
> fit better in gin as we will always need to have some WrapperTypeInfo to
> match against when used in the context of Chromium.
>
> On Fri, Jun 15, 2018 at 12:27 AM 'Daryl Haresign' via v8-dev <
> v8-dev@googlegroups.com> wrote:
>
>> For some reason my replies seem to be automatically deleted :(
>>
>> On Thursday, 14 June 2018 03:17:05 UTC-4, Jochen Eisinger wrote:
>>>
>>> I'd rather move tracing functionality into gin than add more required
>>> embedder fields. Adding the tracing to gin might also be nice once we move
>>> PDFium to use gin bindings.
>>>
>>
>> If this was added to gin, how do you see it working?  The changes I
>> proposed to v8 could be put in gin instead, but we'd still have to come up
>> with a way to get Chromium to ignore them.  Even with the changes solely in
>> v8, we could have a type in our library which matches gin's WrapperInfo,
>> and have an embedder field with a value that doesn't match a value in
>> GinEmbedders.  With this, Chromium wouldn't need any changes as it
>> already checks for kEmbedderBlink.  It would be nicer if this WrapperInfo
>> type was in v8 though.
>>
>> I think checking out gin in addition to v8 is a negligible cost, and I'd
>>> much rather have embedders go through gin than trying  to write their own
>>> bindings.
>>>
>>
>> Again, our bindings work in environments that both have and don't have
>> Chromium, so gin isn't a dependency we really want to introduce to our
>> bindings.
>>
>> On Wed, Jun 13, 2018 at 7:04 PM d.haresign via v8-dev <
>>> v8-...@googlegroups.com> wrote:
>>>
>>>> On Tuesday, 12 June 2018 22:15:01 UTC-4, mlip...@chromium.org wrote:
>>>>>
>>>>> +Jochen Eisinger who is gin
>>>>> <https://cs.chromium.org/chromium/src/gin/?g=0> owner and also has a
>>>>> good overview of the whole Chromium architecture.
>>>>>
>>>>> The Chromium dispatch for the EmbedderHeapTracer currently needs two
>>>>> internal embedder fields and no lookup for a tracer. It requires a
>>>>> suboptimal pattern match on embedder fields that we should optimize 
>>>>> though.
>>>>>
>>>>> I am happy to discuss any improvements on that, especially the
>>>>> matching for whether we should send or not, but the performance for using
>>>>> it in Chromium should stay similar as this is used everywhere for the DOM
>>>>> and Blink is the main embedder.
>>>>>
>>>>
>>>> Understood.  You mentioned having a bit somewhere in the hidden class,
>>>> can you elaborate a bit on that?  I'd be happy to investigate doing this
>>>> instead.
>>>>
>>>> I think that if a project wants to live as an embedder in the
>>>>> Chromium/Blink environment, then it should at least depend on gin. We can
>>>>> then think of adding maybe adding a the dispatcher to gin that then
>>>>> forwards based on the GinEmbedder
>>>>> <https://cs.chromium.org/chromium/src/gin/public/gin_embedders.h?q=GinEmbedder&g=0&l=14>
>>>>>  and
>>>>> set that to V8 to generalize this for the Chromium world. Jochen, wdyt?
>>>>>
>>>>
>>>> I have two concerns about this.  First, from what I can tell, gin seems
>>>> to be part of Chromium, at least in terms of the source distribution, so
>>>> we'd effectively be depending on Chromium.  But second and more
>>>> importantly, we don't always embed alongside Chromium.  Our library is also
>>>> used on the server-side.  For that reason we'd rather just depend on V8 and
>>>> have the same code work in both environments.
>>>>
>>>> Whilst you can put the dispatching tracer somewhere other than V8, I'm
>>>> don't think it's unreasonable to have the logic in V8 itself.
>>>>
>>>> Let me enumerate the changes I think are required in V8:
>>>>
>>>>- Add AddEmbedderHeapTracer and RemoveEmb

Re: [v8-dev] Is Multiple 'EmbedderHeapTracer's Feasible?

[Jochen Eisinger]

I'd rather move tracing functionality into gin than add more required
embedder fields. Adding the tracing to gin might also be nice once we move
PDFium to use gin bindings.

I think checking out gin in addition to v8 is a negligible cost, and I'd
much rather have embedders go through gin than trying  to write their own
bindings.

On Wed, Jun 13, 2018 at 7:04 PM d.haresign via v8-dev <
v8-dev@googlegroups.com> wrote:

> On Tuesday, 12 June 2018 22:15:01 UTC-4, mlip...@chromium.org wrote:
>>
>> +Jochen Eisinger who is gin
>> <https://cs.chromium.org/chromium/src/gin/?g=0> owner and also has a
>> good overview of the whole Chromium architecture.
>>
>> The Chromium dispatch for the EmbedderHeapTracer currently needs two
>> internal embedder fields and no lookup for a tracer. It requires a
>> suboptimal pattern match on embedder fields that we should optimize though.
>>
>> I am happy to discuss any improvements on that, especially the matching
>> for whether we should send or not, but the performance for using it in
>> Chromium should stay similar as this is used everywhere for the DOM and
>> Blink is the main embedder.
>>
>
> Understood.  You mentioned having a bit somewhere in the hidden class, can
> you elaborate a bit on that?  I'd be happy to investigate doing this
> instead.
>
> I think that if a project wants to live as an embedder in the
>> Chromium/Blink environment, then it should at least depend on gin. We can
>> then think of adding maybe adding a the dispatcher to gin that then
>> forwards based on the GinEmbedder
>> <https://cs.chromium.org/chromium/src/gin/public/gin_embedders.h?q=GinEmbedder&g=0&l=14>
>>  and
>> set that to V8 to generalize this for the Chromium world. Jochen, wdyt?
>>
>
> I have two concerns about this.  First, from what I can tell, gin seems to
> be part of Chromium, at least in terms of the source distribution, so we'd
> effectively be depending on Chromium.  But second and more importantly, we
> don't always embed alongside Chromium.  Our library is also used on the
> server-side.  For that reason we'd rather just depend on V8 and have the
> same code work in both environments.
>
> Whilst you can put the dispatching tracer somewhere other than V8, I'm
> don't think it's unreasonable to have the logic in V8 itself.
>
> Let me enumerate the changes I think are required in V8:
>
>- Add AddEmbedderHeapTracer and RemoveEmbedderHeapTracer
>- Deprecate SetEmbedderHeapTracer (make it forward to
>AddEmbedderHeapTracer)
>- LocalEmbedderHeapTracer to store container of remote tracers
>- LocalEmbedderHeapTracer to call all tracers in a loop
>   - NumberOfWrappersToTrace needs to take a sum
>   - AdvanceTracing needs some thought: does it attempt to finish one
>   remote tracer before moving on to the next, or round-robin?
>   - Everything else can just iterate and call
>
> That's basically it.  However there are potentially more changes (e.g. to
> TracePossibleWrappers) when you consider how a third party tracer would
> work in conjunction with Chromium's.
>
> I envisaged that V8 would simply tell all remote tracers about all
> wrappers.  Each tracer would be responsible for filtering out the wrappers
> that don't belong to it.  If there was a "contract" that the first embedder
> field was set to point to the tracer to be used, then the implementation
> would be dead simple:
>
> void ScriptWrappableMarkingVisitor::RegisterV8References(
> const std::vector>&
> internal_fields_of_potential_wrappers) {
>   CHECK(ThreadState::Current());
>   for (auto& pair : internal_fields_of_potential_wrappers) {
> if (pair.first == this) {
>   RegisterV8Reference(pair);
> }
>   }
> }
>
> But there are other options on how to do this, if adding a third field
> would be an unacceptable cost.  We could adjust V8's TracePossibleWrappers
> to not check if the first field is nullptr, and adjust Chromium's 
> RegisterV8References
> to filter out nullptrs.  We can probably come up with a scheme for our
> tracer that works with only one field (though it would be nicer if we had
> access to more than just the first two...)
>
> Thoughts?
> Daryl.
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] how to test wasm fuzzer in v8?

[Jochen Eisinger]

The simple fuzzers not really fuzzers but just testing the libfuzzer
backends against known inputs. Even if you run them using libfuzzer, they
shouldn't output anything - we just test for "not crashing".

On Mon, Jun 5, 2017 at 11:51 AM  wrote:

>
> i want running wasm fuzzer in v8
>
>
> 
>
>
>
> I want to run v8_simple_wasm _ ** _ fuzzer.
>
> So I used the * .wasm file as the .
>
> But there was no reaction.
>
> No log was generated,
>
> No error message is generated.
>
>
> Is it wrong to use a .wasm file as input?
>
> Should I use a file converted to .js?
>
> Or do you need a special .wasm file as the input file?
>
> If my inquiry does not fit here, I apologize if it is wrong.
>
> If there is a group or site discussing wasm in v8, please let me know.
>
>
> Thank you!
>
>
>
>
>
>
>
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] Modifying the V8 C++ API

[Jochen Eisinger]

Hey,

I created a small doc about V8's C++ API design here:
https://chromium.googlesource.com/v8/v8/+/master/include/APIDesign.md

The intention is to help V8 devs working on the V8 C++ API, as opposed to
V8 embedders. For the latter, the embedder's guide is still the main entry
point for information about using the C++ API.

Feel free to extend the document, clarify unclear things, and add missing
pieces!

best
-jochen

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Re: Introduce function_view to src/base

[Jochen Eisinger]

While I can see the benefits of your proposed approach, I'm opposed to
taking in a class that isn't either maintained by chromium or in the STL.
We don't have the bandwidth to maintain a custom wrapper like function_view
ourselves at this point.

On Wed, May 17, 2017 at 6:36 AM  wrote:

> I updated some more codes to function_view (pushed to CL so you can see).
>
> I compare the binaries built from local master branch with current CL
> branch. Even though I have not complete the refactoring yet, size of d8.exe
> and mksnapshot.exe already reduced by 5KB and 15KB respectively.
>
> function_view's implementation has some problem with non-static class
> methods, so I am going to change my plan a bit.
>
> My current idea is:
>
>- If normal function *is passed to* another function as parameter, use
>raw function pointer (as done in some V8 codes).
>- If lambda function with capture and/or normal function *is passed to*
>another function as parameter, use function_view.
>- For other case when you need to pass/*store* normal function, lambda
>function and non-static class methods, use std::function.
>
> I might port Chromium's Callback<> to V8 for CodeAssemblerCallback, but
> that will be a separated CL because the work is non-trivial for me. Looking
> at he implementation of Callback, I think it is almost as complex as (if
> not more than) std:function, so it isn't exactly lightweight.
>
> What do you think?
>
> On Tuesday, May 16, 2017 at 9:43:02 PM UTC+8, looro...@gmail.com wrote:
>>
>> On Tuesday, May 16, 2017 at 9:13:32 PM UTC+8, Jochen Eisinger wrote:
>>>
>>> I'd vote for either importing chromium's base version, or sticking with
>>> the pure C++ version
>>>
>>
>> I can try to look for more V8 code that can be benefited from Callback<>.
>> In my opinion Callable<>'s syntax is quite different from std::function or
>> function_view.
>>
>> std::function was used in the first case only because they need to use
>> lambda function. Most V8 codes just use raw function pointer directly (e.g:
>> https://cs.chromium.org/chromium/src/v8/src/codegen.h?type=cs&l=97)
>>
>> Docs:
>> https://chromium.googlesource.com/chromium/src/+/master/docs/callback.md
>>
>>
>>>
>>> On Tue, May 16, 2017 at 3:12 PM  wrote:
>>>
>>>> On Tuesday, May 16, 2017 at 9:05:41 PM UTC+8, Camillo Bruni wrote:
>>>>>
>>>>> FYI, the code in src/builtin/builtin-*-gen.cc  is no longer shipped
>>>>> and is neither performance critical as it is only used to create the code
>>>>> stubs for the snapshot.
>>>>>
>>>>
>>>> I am aware of that. I noted that in one comment of the CL, but forgot
>>>> to re-mention it again in this thread. src/runtime/runtime-regexp.cc and
>>>> other codes also use a bit of std::function + lambda, so this refactoring
>>>> will still benefit snapshot build slightly.
>>>>
>>>> By the way, Official Node.js binary is built with snapshot or nosnaphot
>>>> configuration?
>>>>
>>>>
>>>>>
>>>>> On Tue, May 16, 2017 at 2:52 PM  wrote:
>>>>>
>>>> On Tuesday, May 16, 2017 at 8:34:43 PM UTC+8, Jochen Eisinger wrote:
>>>>>>>
>>>>>>> Thanks for the summary!
>>>>>>>
>>>>>>> I'm wondering whether you also plan other refactoring work for V8?
>>>>>>>
>>>>>>
>>>>>> No, I only have plan for this refactoring for now.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Also, why not just import base::Bind and friends from Chromium?
>>>>>>>
>>>>>>
>>>>>> Chromium's implementation uses many other Chromium-specific features
>>>>>> like weak_ptr<>, we might end up introducing more code than V8 actually
>>>>>> needs. As far as I can see, CodeAssemblerCallback seems to be the only 
>>>>>> use
>>>>>> case of std::function that might benefit from Chromium's Callable<>.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Tue, May 16, 2017 at 2:04 PM  wrote:
>>>>>>>
>>>>>>>> Hi V8 devs,
>>>>>>>>
>>>>>>>> I saw a few functions in src/builtin/builtin-*-gen.cc and
>>>>>>>&

Re: [v8-dev] Re: Introduce function_view to src/base

[Jochen Eisinger]

I'd vote for either importing chromium's base version, or sticking with the
pure C++ version

On Tue, May 16, 2017 at 3:12 PM  wrote:

> On Tuesday, May 16, 2017 at 9:05:41 PM UTC+8, Camillo Bruni wrote:
>>
>> FYI, the code in src/builtin/builtin-*-gen.cc  is no longer shipped and
>> is neither performance critical as it is only used to create the code stubs
>> for the snapshot.
>>
>
> I am aware of that. I noted that in one comment of the CL, but forgot to
> re-mention it again in this thread. src/runtime/runtime-regexp.cc and other
> codes also use a bit of std::function + lambda, so this refactoring will
> still benefit snapshot build slightly.
>
> By the way, Official Node.js binary is built with snapshot or nosnaphot
> configuration?
>
>
>>
>> On Tue, May 16, 2017 at 2:52 PM  wrote:
>>
> On Tuesday, May 16, 2017 at 8:34:43 PM UTC+8, Jochen Eisinger wrote:
>>>>
>>>> Thanks for the summary!
>>>>
>>>> I'm wondering whether you also plan other refactoring work for V8?
>>>>
>>>
>>> No, I only have plan for this refactoring for now.
>>>
>>>
>>>>
>>>> Also, why not just import base::Bind and friends from Chromium?
>>>>
>>>
>>> Chromium's implementation uses many other Chromium-specific features
>>> like weak_ptr<>, we might end up introducing more code than V8 actually
>>> needs. As far as I can see, CodeAssemblerCallback seems to be the only use
>>> case of std::function that might benefit from Chromium's Callable<>.
>>>
>>>
>>>>
>>>> On Tue, May 16, 2017 at 2:04 PM  wrote:
>>>>
>>>>> Hi V8 devs,
>>>>>
>>>>> I saw a few functions in src/builtin/builtin-*-gen.cc and
>>>>> src/code-stub-assembler.h uses quite a few std::function as a parameter,
>>>>> then pass lambda function to these functions to avoid code duplication as
>>>>> much as possible. std::function was used because raw function pointer 
>>>>> can't
>>>>> accept lambda function.
>>>>>
>>>>> However, because std::function is really powerful, it comes with a
>>>>> cost in terms of code size and overhead when calling std::function.
>>>>>
>>>>> I am working on introducing function_view to src/base, a lightweight
>>>>> callable reference that can accept normal and lambda function.
>>>>>
>>>>> function_view is adapted from [1]
>>>>> <https://vittorioromeo.info/index/blog/passing_functions_to_functions.html>.
>>>>> I have changed it so that it can be compiled with C++11, which is the
>>>>> minimum compiler support requirement to build Chromium.
>>>>>
>>>>> Note:
>>>>>
>>>>> The callable itself must be alive longer or equal to the life time of
>>>>> function_view object. Therefore, function_view is not a universal
>>>>> replacement for the general-purpose std::function.
>>>>>
>>>>> If you need to store lambda function as class property, std::function
>>>>> is still needed. Use case like [2]
>>>>> <https://cs.chromium.org/chromium/src/v8/src/compiler/code-assembler.h?type=cs&l=601>
>>>>> cannot be replaced with function_view.
>>>>>
>>>>> Chromium do have a very powerful library to store callback at
>>>>> https://cs.chromium.org/chromium/src/base/bind_internal.h
>>>>> (std::function is banned in Chromium).
>>>>>
>>>>> Plan:
>>>>>
>>>>>- Add base::function_view implementation to src/base/functional.h
>>>>>- Convert std::function to base::function_view in
>>>>>src/builtin/builtin-*-gen.cc and maybe other parts of src/* if 
>>>>> appropriate.
>>>>>Usage of std::function in test/* will be ignored.
>>>>>- Add documentation.
>>>>>- Add unittest.
>>>>>
>>>>> src/compiler/s390/instruction-selector-s390.cc also uses a lot of
>>>>> std::function + lambda, but because I can't test on this platform myself, 
>>>>> I
>>>>> don't feel safe to change it. It looks like dry run does not have bot for
>>>>> s390.
>>>>>
>>>>> WIP CL:
>>>>>
>>>>> https://chromium-review.googles

[v8-dev] Re: Introduce function_view to src/base

[Jochen Eisinger]

Thanks for the summary!

I'm wondering whether you also plan other refactoring work for V8?

Also, why not just import base::Bind and friends from Chromium?

On Tue, May 16, 2017 at 2:04 PM  wrote:

> Hi V8 devs,
>
> I saw a few functions in src/builtin/builtin-*-gen.cc and
> src/code-stub-assembler.h uses quite a few std::function as a parameter,
> then pass lambda function to these functions to avoid code duplication as
> much as possible. std::function was used because raw function pointer can't
> accept lambda function.
>
> However, because std::function is really powerful, it comes with a cost in
> terms of code size and overhead when calling std::function.
>
> I am working on introducing function_view to src/base, a lightweight
> callable reference that can accept normal and lambda function.
>
> function_view is adapted from [1]
> .
> I have changed it so that it can be compiled with C++11, which is the
> minimum compiler support requirement to build Chromium.
>
> Note:
>
> The callable itself must be alive longer or equal to the life time of
> function_view object. Therefore, function_view is not a universal
> replacement for the general-purpose std::function.
>
> If you need to store lambda function as class property, std::function is
> still needed. Use case like [2]
> 
> cannot be replaced with function_view.
>
> Chromium do have a very powerful library to store callback at
> https://cs.chromium.org/chromium/src/base/bind_internal.h (std::function
> is banned in Chromium).
>
> Plan:
>
>- Add base::function_view implementation to src/base/functional.h
>- Convert std::function to base::function_view in
>src/builtin/builtin-*-gen.cc and maybe other parts of src/* if appropriate.
>Usage of std::function in test/* will be ignored.
>- Add documentation.
>- Add unittest.
>
> src/compiler/s390/instruction-selector-s390.cc also uses a lot of
> std::function + lambda, but because I can't test on this platform myself, I
> don't feel safe to change it. It looks like dry run does not have bot for
> s390.
>
> WIP CL:
>
> https://chromium-review.googlesource.com/c/505653/
>
> [1]:
> https://vittorioromeo.info/index/blog/passing_functions_to_functions.html
> [2]:
> https://cs.chromium.org/chromium/src/v8/src/compiler/code-assembler.h?type=cs&l=601
>
> Sincerely,
> Rong Jie
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] About v8 heap compaction on M55

[Jochen Eisinger]

Please please don't ship a product based on M48 - it's full of known severe
security holes, long fixed bugs, and meanwhile outdated HTML and JavaScript
support.

For the sake of your users, please don't.

Jiadong Zhu  schrieb am Di., 9. Mai 2017, 08:10:

> Hi,
>
> It is said there is v8 memory optimization about heap compact on chrome
> 55. (as follows)
>
>
> http://pressks.com/sci-tech/google-chrome-update-version-55-consumes-lesser-ram-google-promises/7397/
>
> we are android manufacturer and we need to reduce memory based on chromium
> 48,
> we would like to know is there any key patches or in M55 or document about
> heap compaction optimization we could have a look for reference.
>
>
> Thanks,
> Jiadong
>
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Significance of Builtins::AllowDynamicFunction

[Jochen Eisinger]

On Fri, Mar 31, 2017 at 2:54 PM Jens Widell  wrote:

> On Fri, Mar 31, 2017 at 2:24 PM, Jochen Eisinger 
> wrote:
> >
> >
> > On Fri, Mar 31, 2017 at 1:38 PM Jens Widell  wrote:
> >>
> >> Hi all,
> >>
> >> while working on getting the "Entry realm" correct in Blink [1], I
> >> might end up changing how V8 handles the entered context, essentially
> >> relying more on the external caller manually entering a context before
> >> calling V8. Currently, V8 usually enters the argument context
> >> implicitly when its external API is used to e.g. call a function or
> >> set a property.
> >>
> >> Anyhow, when looking for uses of the entered context inside V8, I
> >> think I only found one: Builtins::AllowDynamicFunction(). AFAICT, it's
> >> consulted by the function constructor and global eval(), as well as by
> >> the promise implementations (in ways I don't quite understand, from
> >> lack of reading the code.)
> >>
> >> Why are we looking at the entered context here, rather than the current
> >> context?
> >
> >
> > The short answer is that the current context always has access to
> itself, so
> > the check would be pointless :)
>
> Naturally. :-)
>
> It wasn't immediately obvious that the "right-hand side" was the
> current context though; it's a JSFunction and a global proxy. Those
> could have belonged to some other context, or so I was thinking.
>
>
> > slightly longer answer:
> >
> > AllowDynamicFunction is a safety net for cases where Blink ends up
> injecting
> > an cross origin object into another context that shouldn't have access to
> > that object. In such a situation, we at least disallow injecting code
> into
> > the context of the object.
> >
> > We detect such a situation by checking that the entered context has
> access
> > to the current context before injecting code into the current context.
>
> Are there such (known) cases, or is this done to reduce the harm done
> in case there turns out to be a bug in Blink that leads to this?
>

The latter. There are use counters for all three places that do the check,
and they're all luckily at zero :)


>
>
> > This check really only makes sense for Blink, and assumes that the
> entered
> > context is what the html spec says it is, so doing your cleanup should be
> > fine!
>
> Right, so then we should be good. Thanks for the quick answer!
>
> --
> Jens
>
>
> > Note that the microtask spec sadly doesn't say what context should be
> > entered for a microtask, however, just using whatever context happens to
> be
> > the entered context for microtasks also doesn't make sense. Therefore, v8
> > has this concept of an microtask context which is the creationcontext of
> the
> > promise constructor that was used to create the promise that ended up
> > creating the microtask.
> >
> > For this, we check that the entered context has access to the creation
> > context of the promise constructor when creating the context, and then
> > during microtask execution check that the microtask context as defined
> above
> > has access to the current context.
> >
> > hth
> > -jochen
> >
> >>
> >> By potentially changing what is the entered context in a given
> >> situation, what could go wrong, given this use of it?
> >>
> >> --
> >> Jens
> >>
> >> [1]
> >>
> https://groups.google.com/a/chromium.org/d/msg/platform-architecture-dev/LiDcFt-CqQQ/4olI-faCCAAJ
> >>
> >> --
> >> --
> >> v8-dev mailing list
> >> v8-dev@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.
> >
> > --
> > --
> > v8-dev mailing list
> > v8-dev@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.
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Significance of Builtins::AllowDynamicFunction

[Jochen Eisinger]

On Fri, Mar 31, 2017 at 1:38 PM Jens Widell  wrote:

> Hi all,
>
> while working on getting the "Entry realm" correct in Blink [1], I
> might end up changing how V8 handles the entered context, essentially
> relying more on the external caller manually entering a context before
> calling V8. Currently, V8 usually enters the argument context
> implicitly when its external API is used to e.g. call a function or
> set a property.
>
> Anyhow, when looking for uses of the entered context inside V8, I
> think I only found one: Builtins::AllowDynamicFunction(). AFAICT, it's
> consulted by the function constructor and global eval(), as well as by
> the promise implementations (in ways I don't quite understand, from
> lack of reading the code.)
>
> Why are we looking at the entered context here, rather than the current
> context?
>

The short answer is that the current context always has access to itself,
so the check would be pointless :)

slightly longer answer:

AllowDynamicFunction is a safety net for cases where Blink ends up
injecting an cross origin object into another context that shouldn't have
access to that object. In such a situation, we at least disallow injecting
code into the context of the object.

We detect such a situation by checking that the entered context has access
to the current context before injecting code into the current context.

This check really only makes sense for Blink, and assumes that the entered
context is what the html spec says it is, so doing your cleanup should be
fine!

Note that the microtask spec sadly doesn't say what context should be
entered for a microtask, however, just using whatever context happens to be
the entered context for microtasks also doesn't make sense. Therefore, v8
has this concept of an microtask context which is the creationcontext of
the promise constructor that was used to create the promise that ended up
creating the microtask.

For this, we check that the entered context has access to the creation
context of the promise constructor when creating the context, and then
during microtask execution check that the microtask context as defined
above has access to the current context.

hth
-jochen


> By potentially changing what is the entered context in a given
> situation, what could go wrong, given this use of it?
>
> --
> Jens
>
> [1]
> https://groups.google.com/a/chromium.org/d/msg/platform-architecture-dev/LiDcFt-CqQQ/4olI-faCCAAJ
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] how to integrate V8 into a Visual Studio project?

[Jochen Eisinger]

to get those files, you need to set v8_static_library = true in your gn
args (only works on latest v8 dev versions)

On Fri, Jan 6, 2017 at 7:40 PM  wrote:

> hi all,
>
> I'm trying to compile and run the v8 "hello world" example but ran into
> numerous linking errors.  I was able to compile v8 with both gn and visual
> studio.  gn build creates sample executables that runs ok.  The output from
> Visual Studio (v8.sln) build is a bunch of lib files:
> icui18n.lib
> icuuc.lib
> v8_base_x.lib (x=0 to 3)
> v8_external_snapshot.lib
> v8_libbase.lib
> v8_libplatform.lib
> v8_libsampler.lib
> v8_nosnapshot.lib
> v8_snapshot.lib
>
> I've seen people talking about two more:
> v8.lib
> v8_base.lib
>
> But I don't see these in the output.
>
> In order to resolve link errors, which files are needed ?
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Does WeakCell store weak references?

[Jochen Eisinger]

Yes, that's how a WeakCell works.

I'm not sure, however, I understand what you're doing with the slots there,
and what you mean by the WeakCell becoming free space (the WeakCell should
always stay alive, it's just the link to whatever object it points to that
gets cleared)?

On Sun, Dec 11, 2016 at 1:05 AM  wrote:

> Does anyone know how to create weak references internally in V8? I came
> across the WeakCell type (subclassed from HeapObject) in src/objects.h. It
> provides methods cleared() and value(), and I guess the cleared() method is
> used to test if the referenced object has been freed by the GC, while
> value() gives pointer to the referenced object. Is this understanding
> correct?
>
> I have created a couple Object ** slots to store pointers to WeakCell *.
> During GC I iterated the Object ** slots using VisitPointer(). But after a
> few GC cycles (~2) I would see some WeakCell's become free space. Is this
> the correct behavior? If it becomes free space, immediately after GC (I
> hooked GarbageCollectionEpilogue), can we safely assume that the referenced
> object has been recycled?
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] strict build for developers which treat non numeric values in math operations as exception

[Jochen Eisinger]

Given the many places that are affected by number handling, I'd say this is
not possible.

Several JS frameworks provide ways to navigate some of the rougher edges
here, have you considered using one that provides the kind of math
guarantees you're looking for?

On Sun, Dec 11, 2016 at 6:07 AM  wrote:

> Is it good idea to make dev build of v8, which will treat not-numeric or
> NaN values in any Math, +, -, *, / ^, and e.t.c. operatons as exception? I
> think its will save a lot of time for js developers.
> Is exists something like that or any one can help to add it?
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] what went wrong?

[Jochen Eisinger]

did you run gclient sync? is "depot_tools" in your $PATH?

On Tue, Nov 8, 2016 at 4:40 AM Jason Zoo  wrote:

> tools/dev/v8gen.py x64.debug -vv
>
> 
> /usr/bin/python -u tools/mb/mb.py gen -f infra/mb/mb_config.pyl -m
> developer_default -b x64.debug out.gn/x64.debug
>
>   Writing """\
>   is_debug = true
>   target_cpu = "x64"
>   v8_enable_backtrace = true
>   v8_enable_slow_dchecks = true
>   v8_optimized_debug = false
>   """ to /home/jason/work/git/v8/out.gn/x64.debug/args.gn.
>
>   /home/zhujianchen/work/git/v8/buildtools/linux64/gn gen out.gn/x64.debug
> --check
>   Traceback (most recent call last):
> File "tools/mb/mb.py", line 60, in Main
>   ret = self.args.func()
> File "tools/mb/mb.py", line 257, in CmdGen
>   return self.RunGNGen(vals)
> File "tools/mb/mb.py", line 780, in RunGNGen
>   ret, _, _ = self.Run(cmd)
> File "tools/mb/mb.py", line 1375, in Run
>   ret, out, err = self.Call(cmd, env=env, buffer_output=buffer_output)
> File "tools/mb/mb.py", line 1389, in Call
>   env=env)
> File "/usr/lib/python2.7/subprocess.py", line 711, in __init__
>   errread, errwrite)
> File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
>   raise child_exception
>   OSError: [Errno 2] No such file or directory
> Traceback (most recent call last):
>   File "tools/dev/v8gen.py", line 304, in 
> sys.exit(gen.main())
>   File "tools/dev/v8gen.py", line 298, in main
> return self._options.func()
>   File "tools/dev/v8gen.py", line 166, in cmd_gen
> gn_outdir,
>   File "tools/dev/v8gen.py", line 208, in _call_cmd
> stderr=subprocess.STDOUT,
>   File "/usr/lib/python2.7/subprocess.py", line 574, in check_output
> raise CalledProcessError(retcode, cmd, output=output)
> subprocess.CalledProcessError: Command '['/usr/bin/python', '-u',
> 'tools/mb/mb.py', 'gen', '-f', 'infra/mb/mb_config.pyl', '-m',
> 'developer_default', '-b', 'x64.debug', 'out.gn/x64.debug']' returned
> non-zero exit status 1
>
> I exec `tools/dev/v8gen.py x64.debug`,It went wrong with me? Any solution
> for me ? thks~
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Questions about concurrent recompilation for Crankshaft

[Jochen Eisinger]

On Thu, Nov 10, 2016 at 9:30 PM Jay  wrote:

> Hi,
>
> I have some questions about concurrent recompilation for Crankshaft.
>
> 1. Crankshaft's compilation is 3-step: CreateGraph, OptimizeGraph and
> GenerateCode.  It seems like only the second step is done on the background
> thread concurrently.  What prevents the other steps to be parallelized as
> well?
>

The other steps access javascript objects on the heap, an operation that is
not thread-safe in v8.


>
> 2. It seems like that it does not use concurrent recompilation for OSR.
> Why is it?
>

For OSR, we need the code as soon as possible. We used to use concurrent
recompilation for this, but it often happened that when the code was
compiled, we no longer needed it.


>
> Thanks,
> Jay
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Why sort slower in v8 vs js?

[Jochen Eisinger]

No, I'm talking about the two for loops.

I'd expect that if you want to transfer large amounts of data back and
forth, you'll get better results by using typed arrays.

On Tue, Oct 25, 2016 at 7:10 AM Samantha Krieger 
wrote:

> Thanks for responding!
>
> OK I assume you're talking about the overhead associated largely with
> these lines:
>
> Isolate* isolate = Isolate::GetCurrent();
>HandleScope scope(isolate);
>
>if (args.Length() < 1 || !args[0]->IsArray()) {
>   isolate->ThrowException(
> Exception::TypeError(
>   String::NewFromUtf8(isolate,
> "First argument should be an array")));
>   return;
>}
>
>Handle arr = Handle::Cast(args[0]);
>
> 
>
>
> If that is the case:
>
> 1) Wouldn't the overhead get amortized with larger array size? (Presumably
> the answer is no so why not?)
> 2) Is there anything I can do to minimize that overhead? It was my
> understanding that using Isolates and Handle Scopes are a part of the
> necessary boiler plate. Can they be avoided?
> (3) What about them causes so much overhead if they are the ones
> responsible?)
>
> Really appreciate all the help Thanks so much again!
>
> On Monday, October 24, 2016 at 3:42:00 AM UTC-4, Jochen Eisinger wrote:
>
> compared to the JS function, the C implementation has a lot of overhead to
> copy the data back and forth, so it's not surprising that this overhead
> shows up especially on larger arrays
>
> On Mon, Oct 24, 2016 at 2:47 AM Samantha Krieger 
> wrote:
>
> Just wondering if I'm crazy/doing something incredibly stupid.
>
> I wrote this sort function using v8 (wrapper around qsort):
>
> void Sort(const FunctionCallbackInfo& args) {
>Isolate* isolate = Isolate::GetCurrent();
>HandleScope scope(isolate);
>
>if (args.Length() < 1 || !args[0]->IsArray()) {
>   isolate->ThrowException(
> Exception::TypeError(
>   String::NewFromUtf8(isolate,
> "First argument should be an array")));
>   return;
>}
>
>Handle arr = Handle::Cast(args[0]);
>int size = arr->Length();
>double other_arr[size];
>for (int i = 0; i < size; i++){
>   other_arr[i] = arr->Get(i)->NumberValue();
>}
>
>
>qsort(other_arr, size, sizeof(other_arr[0]), compare);
>Handle res = Array::New(isolate, size);
>for (int i = 0; i < size; ++i) {
> //  printf ("I val: %f\n",other_arr[i]);
>   res->Set(i, Number::New(isolate, other_arr[i]));
>}
>
>args.GetReturnValue().Set(res);
>
> }
>
>
>
> when i run it in js from node, its markedly slower than the equivalent js 
> sort (which I understand v8 [].sort() uses qsort under the hood) for objects 
> between 1000 - 1+
>
>
> var sort = require('bindings')('sort.node');
>
>
> function benchmarkSort(size){
>
>  var arr = helpers.generateArray(size);
>  var cres = benchmark(sort.sort, [arr], 10);
>
>
>  var arr = helpers.generateArray(size);
>  var jsres = benchmark(helpers.sort, [arr], 10);
>  return {
>   c: cres,
>   js: jsres
>  };
>
> }
>
>
> function benchmark(fn, args, times){
>  var noTimes = (typeof times != 'undefined'? times: NO_TIMES);
>  var start = Date.now();
>  var result = run(fn, noTimes, args);
>  var duration = Date.now() - start;
>  return duration;
> }
>
>
>  - Cost for sorting 100 ---
> JS time: 1 msec
> C time: 1 msec
>  - Cost for sorting 1000 ---
> JS time: 4 msec
> C time: 3 msec
>  - Cost for sorting 1 ---
> JS time: 22 msec
> C time: 37 msec
>  - Cost for sorting 10 ---
> JS time: 278 msec
> C time: 441 msec
>
>
> These results seem incredibly strange. Am I doing something incredibly 
> stupid/missing something? Can someone explain whats going on? Much 
> appreciated
>
> --
> --
> 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+un...@googlegroups.com.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Why sort slower in v8 vs js?

[Jochen Eisinger]

compared to the JS function, the C implementation has a lot of overhead to
copy the data back and forth, so it's not surprising that this overhead
shows up especially on larger arrays

On Mon, Oct 24, 2016 at 2:47 AM Samantha Krieger 
wrote:

> Just wondering if I'm crazy/doing something incredibly stupid.
>
> I wrote this sort function using v8 (wrapper around qsort):
>
> void Sort(const FunctionCallbackInfo& args) {
>Isolate* isolate = Isolate::GetCurrent();
>HandleScope scope(isolate);
>
>if (args.Length() < 1 || !args[0]->IsArray()) {
>   isolate->ThrowException(
> Exception::TypeError(
>   String::NewFromUtf8(isolate,
> "First argument should be an array")));
>   return;
>}
>
>Handle arr = Handle::Cast(args[0]);
>int size = arr->Length();
>double other_arr[size];
>for (int i = 0; i < size; i++){
>   other_arr[i] = arr->Get(i)->NumberValue();
>}
>
>
>qsort(other_arr, size, sizeof(other_arr[0]), compare);
>Handle res = Array::New(isolate, size);
>for (int i = 0; i < size; ++i) {
> //  printf ("I val: %f\n",other_arr[i]);
>   res->Set(i, Number::New(isolate, other_arr[i]));
>}
>
>args.GetReturnValue().Set(res);
>
> }
>
>
>
> when i run it in js from node, its markedly slower than the equivalent js 
> sort (which I understand v8 [].sort() uses qsort under the hood) for objects 
> between 1000 - 1+
>
>
> var sort = require('bindings')('sort.node');
>
>
> function benchmarkSort(size){
>
>  var arr = helpers.generateArray(size);
>  var cres = benchmark(sort.sort, [arr], 10);
>
>
>  var arr = helpers.generateArray(size);
>  var jsres = benchmark(helpers.sort, [arr], 10);
>  return {
>   c: cres,
>   js: jsres
>  };
>
> }
>
>
> function benchmark(fn, args, times){
>  var noTimes = (typeof times != 'undefined'? times: NO_TIMES);
>  var start = Date.now();
>  var result = run(fn, noTimes, args);
>  var duration = Date.now() - start;
>  return duration;
> }
>
>
>  - Cost for sorting 100 ---
> JS time: 1 msec
> C time: 1 msec
>  - Cost for sorting 1000 ---
> JS time: 4 msec
> C time: 3 msec
>  - Cost for sorting 1 ---
> JS time: 22 msec
> C time: 37 msec
>  - Cost for sorting 10 ---
> JS time: 278 msec
> C time: 441 msec
>
>
> These results seem incredibly strange. Am I doing something incredibly 
> stupid/missing something? Can someone explain whats going on? Much 
> appreciated
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] When to use which macro for component builds

[Jochen Eisinger]

On Mon, Oct 17, 2016 at 11:39 PM Adam Klein  wrote:

> On Mon, Oct 17, 2016 at 8:18 AM, Jochen Eisinger 
> wrote:
>
>
>
> On Fri, Oct 14, 2016 at 8:19 PM Adam Klein  wrote:
>
> I take it from your omission that code which isn't accessed anywhere but
> within src doesn't need any export macro?
>
>
> well, within the same compilation unit.
>
> If src/d8.cc access something in src/factory.h the latter needs to be
> exported. (d8.cc goes into d8 while factory.h goes into v8_base).
>
>
> Do you mean something other than "compilation unit" ("shared library",
> perhaps?) here? I think of a compilation unit as being, e.g., "factory.cc
> and all its includes" (which generates factory.o). So the example would be,
> what if I access something in factory.h from objects.cc?
>

Ehrm, yes, "component" in gn terms, or shared library, not compilation unit.

objects.cc can access stuff in factory.h without any annotations.


>
>
> Same holds true for src/ vs src/base.
>
> best
> -jochen
>
>
>
> On Fri, Oct 14, 2016 at 6:47 AM, Jochen Eisinger 
> wrote:
>
> Hey,
>
> we recently started to support component builds for almost all binaries.
> With this, it might happen that debug bots fail to link because they can't
> find certain symbols.
>
> Here is what to do:
>
> If the symbol is supposed to be visible to embedders, e.g., it's in
> include/v8.h, then add the V8_EXPORT macro.
>
> If the symbol is used by tests only, e.g., it's in src/, add the
> V8_EXPORT_PRIVATE (defined in src/globals.h) macro (or if it's in src/base/
> V8_BASE_EXPORT defined in src/base/base-export.h or in src/libplatform
> V8_PLATFORM_EXPORT defined in include/libplatform/libplatform-export.h)
>
> Annotate classes like this:
>
> class V8_EXPORT Foo {
> };
>
> or individual methods or functions like this
>
> V8_EXPORT bool DoStuff();
>
> For the public API (V8_EXPORT) we generally export everything. For test
> only stuff, we might wish to not export some base classes. In that
> situation, you have to annotate the base classes with NON_EXPORTED_BASE
> defined in src/base/compiler-specific.h like this:
>
> class V8_EXPORT_PRIVATE Foo : public NON_EXPORTED_BASE(Bar) {
> };
>
> If you annotated everything, but e.g. a symbol from src/base is still not
> found, it might be that the executable does not depend on v8_libbase (in
> this example) - you'll have to add the dependency in the BUILD.gn (and
> corresponding gyp file) then - but this should be rare, only if you add new
> binaries.
>
> best
> -jochen
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] When to use which macro for component builds

[Jochen Eisinger]

On Fri, Oct 14, 2016 at 8:19 PM Adam Klein  wrote:

> I take it from your omission that code which isn't accessed anywhere but
> within src doesn't need any export macro?
>

well, within the same compilation unit.

If src/d8.cc access something in src/factory.h the latter needs to be
exported. (d8.cc goes into d8 while factory.h goes into v8_base).

Same holds true for src/ vs src/base.

best
-jochen


>
> On Fri, Oct 14, 2016 at 6:47 AM, Jochen Eisinger 
> wrote:
>
> Hey,
>
> we recently started to support component builds for almost all binaries.
> With this, it might happen that debug bots fail to link because they can't
> find certain symbols.
>
> Here is what to do:
>
> If the symbol is supposed to be visible to embedders, e.g., it's in
> include/v8.h, then add the V8_EXPORT macro.
>
> If the symbol is used by tests only, e.g., it's in src/, add the
> V8_EXPORT_PRIVATE (defined in src/globals.h) macro (or if it's in src/base/
> V8_BASE_EXPORT defined in src/base/base-export.h or in src/libplatform
> V8_PLATFORM_EXPORT defined in include/libplatform/libplatform-export.h)
>
> Annotate classes like this:
>
> class V8_EXPORT Foo {
> };
>
> or individual methods or functions like this
>
> V8_EXPORT bool DoStuff();
>
> For the public API (V8_EXPORT) we generally export everything. For test
> only stuff, we might wish to not export some base classes. In that
> situation, you have to annotate the base classes with NON_EXPORTED_BASE
> defined in src/base/compiler-specific.h like this:
>
> class V8_EXPORT_PRIVATE Foo : public NON_EXPORTED_BASE(Bar) {
> };
>
> If you annotated everything, but e.g. a symbol from src/base is still not
> found, it might be that the executable does not depend on v8_libbase (in
> this example) - you'll have to add the dependency in the BUILD.gn (and
> corresponding gyp file) then - but this should be rare, only if you add new
> binaries.
>
> best
> -jochen
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] When to use which macro for component builds

[Jochen Eisinger]

Hey,

we recently started to support component builds for almost all binaries.
With this, it might happen that debug bots fail to link because they can't
find certain symbols.

Here is what to do:

If the symbol is supposed to be visible to embedders, e.g., it's in
include/v8.h, then add the V8_EXPORT macro.

If the symbol is used by tests only, e.g., it's in src/, add the
V8_EXPORT_PRIVATE (defined in src/globals.h) macro (or if it's in src/base/
V8_BASE_EXPORT defined in src/base/base-export.h or in src/libplatform
V8_PLATFORM_EXPORT defined in include/libplatform/libplatform-export.h)

Annotate classes like this:

class V8_EXPORT Foo {
};

or individual methods or functions like this

V8_EXPORT bool DoStuff();

For the public API (V8_EXPORT) we generally export everything. For test
only stuff, we might wish to not export some base classes. In that
situation, you have to annotate the base classes with NON_EXPORTED_BASE
defined in src/base/compiler-specific.h like this:

class V8_EXPORT_PRIVATE Foo : public NON_EXPORTED_BASE(Bar) {
};

If you annotated everything, but e.g. a symbol from src/base is still not
found, it might be that the executable does not depend on v8_libbase (in
this example) - you'll have to add the dependency in the BUILD.gn (and
corresponding gyp file) then - but this should be rare, only if you add new
binaries.

best
-jochen

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Does V8 use one stack's for js function and native code?

[Jochen Eisinger]

We use the same stack

Best
Jochen

Dmitriy -  schrieb am Do., 29. Sep. 2016, 12:01:

> For example:
>
> c frame
> js frame
> c frame
> js frame
> js frame
> c frame
>
> OR
>
> c frame
> c frame
> c frame
> c frame
> --
> js frame
> js frame
> js frame
>
> Does V8 separate stack on two parts - JS stack and Native stack?
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Deprecated function in test/cctest/interpreter/generate-bytecode-expectations.cc

[Jochen Eisinger]

Please file a bug at crbug.com/v8/new

thanks
-jochen

On Wed, Sep 28, 2016 at 6:06 PM  wrote:

> I found that the current code on GitHub of V8 uses a deprecated function,
> namely readdir_r (more about it here:
> http://man7.org/linux/man-pages/man3/readdir_r.3.html). I am not able to
> correct the code because I don't fully understand how it works, but I
> wanted to help by exposing this problem.
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] gn binary for other platforms

[Jochen Eisinger]

It should be possible to build from source. You'll need a complete chromium
checkout (run fetch chromium). There's a bootstrap script here:
https://chromium.googlesource.com/chromium/src/tools/gn/+/master/bootstrap/bootstrap.py

On Sun, Sep 25, 2016 at 5:58 AM Atiq Rahman  wrote:

> Currently gn binary (for example, buildtools/linux64/gn) is provided for
> linux2, darwin and win. How can we get gn binary for other platforms i.e.,
> Solaris? Or can we build gn from source on other platforms?
>
>
>
> Thanks,
>
> Atiq
>
> v8 build external blog 
>
>
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: Please add new cctests / unittests to both gyp and gn

[Jochen Eisinger]

... and there's now a presubmit check to help you remember that :)

On Wed, Sep 14, 2016 at 9:00 PM Jochen Eisinger  wrote:

> Hey,
>
> with the progress on our gn migration, I disentangled the gyp and gn files
> for cctests and unittests. In the past, it was enough to add a new file to
> the gyp file, and gn would just pick them up. From now on, you will have to
> add new files to both gyp and gn (as you already have to do for src/
> anyways).
>
> best
> -jochen
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] TemplateHashMap changes proposal

[Jochen Eisinger]

would replacing it with std::unordered_map<> gain the same advantages?

On Thu, Sep 15, 2016 at 10:29 AM  wrote:

> Hi all,
>
> We (ignition) are looking to use base/hashmap (TemplateHashMap), but there
> are a couple of things that I want to change/add for efficiency's sake.
> Because these changes would have far-reaching effects, I wanted to send out
> the proposed changes before trying to upload any CLs.
>
> My proposed changes are:
>
>- Template the value type, so that small types (e.g. ints) can be
>stored inline rather than allocated
>- Template the key type, for the same reason
>   - This has some far reaching effects -- e.g. we can't store holes
>   as nullptr keys anymore, but have to have a separate boolean existence
>   flag. I suggest that we have an Entry class that is templated on the 
> key,
>   and specialised for pointer-typed keys to treat null keys as holes.
>- Template the hash function and remove the hash fields, because
>passing in our own hash values is asking for trouble
>- Template the equals/matching function, since we'd be having to
>template it on the key type anyway, to skip that dereference
>- Move the allocator to a field, because passing different allocators
>around as parameters is super sketchy
>   - More precisely, move it to a private base class to take advantage
>   of the empty base-class optimisation
>- Add a function argument to LookupOrInsert which creates the value,
>since the Value type is templated and so we can't rely on null values to
>mean newly-inserted entries
>
> And maybe, though I'm less convinced about these:
>
>- Return value references directly for Lookup/LookupOrInsert, rather
>than Entries, to make Entries non-public
>- Add an stl-like iterator interface rather than Start/Next, also to
>make Entries non-public
>
> Most of these I could wrap in a particular 
> implementation that would fairly closely imitate the original hash map, but
> there would (probably?) still be some differences.
>
> Comments/questions/rage?
>
> - Leszek
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] Please add new cctests / unittests to both gyp and gn

[Jochen Eisinger]

Hey,

with the progress on our gn migration, I disentangled the gyp and gn files
for cctests and unittests. In the past, it was enough to add a new file to
the gyp file, and gn would just pick them up. From now on, you will have to
add new files to both gyp and gn (as you already have to do for src/
anyways).

best
-jochen

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] How to get v8 printf() messages in adb logcat?

[Jochen Eisinger]

If the v8_android_log_stdout gyp define is set to 0, the printf message
should go to the log

On Thu, Aug 18, 2016 at 5:10 PM Singapati  wrote:

> Hello,
>
> How to get v8 printf() messages in adb logcat?
>
> Thank you.
> Sarath
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Re: PSA: In-process stack trace dumping is changing

[Jochen Eisinger]

Great work, thank you!

Some questions:
You only added the initialization call to d8. Will this also work for other
binaries / when run inside chromium?

You also stripped out the libsymbolize specific code. Is there some
functionality we're now missing?

Last but not least, I guess you can now remove the v8_enable_backtrace and
related settings, no?

On Thu, Aug 18, 2016 at 5:57 PM 'Ross McIlroy' via v8-dev <
v8-dev@googlegroups.com> wrote:

> This has now landed.
>
> Cheers
>
>
> Ross
>
> On 18 Aug 2016 12:56 p.m., "Ross McIlroy"  wrote:
>
>> Hi all,
>>
>> *tldr; C stack trace output will change, but we will now get dumps on
>> Windows and on signals / uncaught C++ exceptions in d8.*
>>
>> I'm planing on landing https://codereview.chromium.org/2248393002/ sometime
>> later today. This change removes our current DumpBacktrace code (which only
>> worked on Linux) and replaces it with the implementation used by Chromium.
>>
>> This will give us dumps on Windows. It also enables in-process stack
>> dumping on uncaught signals (e.g., SEGV) or Window's C++ exceptions. I have
>> only enabled in-process stack dumping on signals in the d8 shell (other
>> embedded won't be effected).
>>
>> This shouldn't impact day-to-day debugging (gdb still works as before -
>> see CL comments for details), but should give us some debug information for
>> crashes on the Windows bots [1].
>>
>> As a consequence of this change, the output format of C stack traces
>> (e.g., on CHECK failures) will change somewhat. The new format is a bit
>> more verbose, but contains the same information as before (see CL for
>> details).
>>
>> Unless anyone objects, I'll land this CL later today.
>>
>> Cheers,
>> Ross
>>
>> [1] I'm currently trying to debug a crash which only happens on a single
>> Windows bot, and doesn't repo locally or on the try-bots. A stack-trace
>> would be really useful for this :).
>>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Cannot get stack trace in GC

[Jochen Eisinger]

I guess we could also walk some objects, as long as we teach the stack
frame machinery to follow forwarding pointers.

On Fri, Aug 19, 2016 at 3:43 PM Michael Lippautz 
wrote:

> As you already pointed out, during compaction and new space evacuation the
> GC moves objects around. We cannot assemble a stack trace in this scenario
> because the heap is in an inconsistent state and the stack trace routine
> cannot safely dereference objects anymore.
>
> Continuing is not possible because, well, we ran out of memory.
>
> The only thing I can think of is that we identify parts of the stack trace
> that don't require walking/dereferencing heap objects and assemble those
> parts.
>
> -Michael
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] New gdb macro to skip x64 jitted stack

[Jochen Eisinger]

Hey,

I just landed a new gdb macro "jss" (javascript skip stack) that allows you
to skip a jitted x64 stack:

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7f50d02c4700 (LWP 8152)]
base::debug::(anonymous namespace)::DebugBreak ()
at ../../base/debug/debugger_posix.cc:230
230 }
(gdb) bt
at ../../base/debug/debugger_posix.cc:230
...
args_object=0x7f50d02bfe00, isolate=0x2f001c9e2020)
at ../../v8/src/builtins/builtins-api.cc:123
...
(gdb) jss
(gdb) bt
isolate=0x2f001c9e2020, is_construct=false, target=..., receiver=...,
argc=1, args=0x7f50d02c0518, new_target=...)
at ../../v8/src/execution.cc:111
isolate=0x2f001c9e2020, callable=..., receiver=..., argc=1,
argv=0x7f50d02c0518) at ../../v8/src/execution.cc:168
...

Note that the macro modifies the cpu registers

BR
Jochen

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: PSA: replacing smart pointers with C++11 unique_ptr

[Jochen Eisinger]

This has landed

On Mon, Jul 25, 2016 at 10:46 AM Jochen Eisinger 
wrote:

> Hey,
>
> I'm about to land a CL replacing SmartArrayPointer with
> std::unique_ptr and SmartPointer with std::unique_ptr.
>
> Both should be pretty similar, except for minor naming differences:
>
> Reset -> reset
> Detach -> release
> is_empty -> std::unique_ptr::operator bool
>
> The header that defines unique_ptr is 
>
> MSVS might complain about a deleted operator if you have add a unique_ptr
> member to a class. In that case, you forgot to add
> DISALLOW_COPY_AND_ASSIGN() to your class, or, if you actually want to copy
> it around, you need to implement move constructors.
>
> best
> -jochen
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] PSA: replacing smart pointers with C++11 unique_ptr

[Jochen Eisinger]

Hey,

I'm about to land a CL replacing SmartArrayPointer with
std::unique_ptr and SmartPointer with std::unique_ptr.

Both should be pretty similar, except for minor naming differences:

Reset -> reset
Detach -> release
is_empty -> std::unique_ptr::operator bool

The header that defines unique_ptr is 

MSVS might complain about a deleted operator if you have add a unique_ptr
member to a class. In that case, you forgot to add
DISALLOW_COPY_AND_ASSIGN() to your class, or, if you actually want to copy
it around, you need to implement move constructors.

best
-jochen

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] git cl try now runs a CQ dry run instead of starting bots directly

[Jochen Eisinger]

See the corresponding intent to implement on chromium-dev. This was done so
git cl try would also trigger bots defined via CQ_INCLUDE_TRYBOTS

Adam Klein  schrieb am Fr., 15. Juli 2016, 00:18:

> Was this an intentional change? Unintentional side effect of something
> else? Mostly curious if anyone knows what happened here.
>
> - Adam
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] Fwd: [blink-dev] [ANN] Moving from Rietveld to Gerrit

[Jochen Eisinger]

fyi, as we'll probably continue to use the same codereview tool as the rest
of chromium projects

-- Forwarded message -
From: Andrew Bonventre 
Date: Di., 12. Juli 2016, 23:24
Subject: [blink-dev] [ANN] Moving from Rietveld to Gerrit
To: Chromium-dev , blink-dev <
blink-...@chromium.org>, 


*Summary*
The Chromium project is moving away from Rietveld to a revamped version of
Gerrit for our main Code Review tool.

*When?*
The conservative estimate is Q4 of 2016. There are already some Chromium
teams dogfooding the new Polymer-based UI (called PolyGerrit) and we are
using their feedback to ensure that there is both a smooth transition and
developer needs are met. This process will continue as we onboard more
people.

*Why?*
We (Chromium) are the only customers of Rietveld (codereview.chromium.org
and its internal counterpart) and maintenance of the tool has been
delegated to a single person. The codebase has become a liability over the
years and speed has become a major issue.

Gerrit is a fast, secure, and fully-featured code review tool built as a
successor to Rietveld. It is already used by some Chrome subteams along
with the Android, Go, and Bazel teams (as well as many others both inside
and outside Google). It is also a fully staffed project with heavy
investment from Google. This also means full-time UX support.

Its front-end is being re-written using Polymer, a standards-based library
that allows us to take advantage of Web Components. This UI is the one that
Chromium will be transitioning to (though you are welcome to use the old UI
if you like).

*FAQ*
*Can I see current progress on PolyGerrit?*
Yes. Download this extension

and
then visit https://chromium-review.googlesource.com. You can then toggle
between the two UIs.

*How can I start dogfooding it now?*
We still have plenty to do on the infrastructure side of things before many
teams can move over. If you have a sub-project you think may qualify for
early migration, email me and +Andrii Shyshkalov .

*How can I follow progress?*
All bugs related to the migration have the label Proj-Gerrit-Migration
.
Additionally, on the Gerrit project, there is a list of Chromium-specific
bugs

.

*What will happen to Rietveld?*
Rietveld will be put in read-only mode to preserve change history.
Potential migration of changes to Gerrit will be considered after the
switch. A unified CL search interface is being strongly considered.

*Why not continue to just maintain Rietveld?*
The Chromium infra team is stretched far too thin as it is and keeping the
status quo of having one or no owner for the Rietveld codebase isn’t
tenable given its fragility. The bus factor is just too low. That coupled
with the duplication of effort across the Gerrit and Rietveld projects, it
doesn’t make strategic sense. We would rather focus on more important work
that will bring immediate benefit to Chromium developers.

*Why don’t you move the current Rietveld v2 UI on top of Gerrit?*
The current Rietveld v2 UI is written in Polymer 0.5, which is no longer
supported by the Polymer team. There is a non-trivial amount of work that
will go into porting it to 1.0. In addition, there are certain workflows
within Gerrit that must be supported, so blindly porting the new Rietveld
UI could potentially omit those workflows and cause confusion.

*Will this change my current command-line development workflow?*
No. git cl will support a Rietveld-style workflow with Gerrit
transparently. You can follow this tracking bug to be informed on feature
parity with git cl on Rietveld.

*I heard I can’t “LGTM with nits.” This is a huge productivity loss if I’m
working with people across timezones. Will I have to approve again if the
author uploads another patchset?*
No. Being able to submit a commit that doesn't exactly match the one that
got approved is a per-project configuration option — you can choose in the
config whether approvals are “sticky” or only per-patchset.

*Are you going to go inside a hole for six months, return with a new tool,
and then force everyone to use it?*
No. Developer feedback (both from Chrome devs and current Gerrit users)
will be crucial for the UI rewrite to be a success. We will be as
transparent as possible with progress and will establish a feedback loop
very early on. This isn’t about just alleviating maintenance burden, but
making a tool that is crucial to everyone’s workflow better.

If you have any questions or need clarification, please don’t hesitate to
reach out.
Andy

-- 
-- 
v8-dev mailing list
v8-dev@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 receivi

[v8-dev] Design doc for OOPIF / v8 context support

['Jochen Eisinger' via v8-dev]

Hey,

I'm currently landing some V8 changes to allow for constructing lightweight
RemoteFrames, i.e., without a full v8::Context attached. Outline here:
https://docs.google.com/document/d/1QQZgXnC4xSAnRmNCZvMnXfO4PYzNh0lL3rS8mPEwptI/edit?usp=sharing

tracking bug here:
https://bugs.chromium.org/p/chromium/issues/detail?id=618305

best
-jochen

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] fetch failing on recently released Fedora 24

[Jochen Eisinger]

sorry, I have no experience with setting this up either. I'd recommend
asking on one of the google cloud support lists for help.

On Thu, Jun 30, 2016 at 10:10 PM Atiq Rahman  wrote:

> It is confusing. Can you please provide a command example with a boto
> config file? The ones I am trying is not working.
>
>
>
> Thanks,
>
> Atiq
>
>
>
> *From:* v8-dev@googlegroups.com [mailto:v8-dev@googlegroups.com] *On
> Behalf Of *Jochen Eisinger
> *Sent:* Thursday, June 30, 2016 1:21 AM
>
>
> *To:* v8-dev@googlegroups.com
> *Subject:* Re: [v8-dev] fetch failing on recently released Fedora 24
>
>
>
> AFAIK gsutil respects that boto config file:
> https://cloud.google.com/storage/docs/boto-gsutil#config
>
>
>
> On Sat, Jun 25, 2016 at 1:55 AM Atiq Rahman  wrote:
>
> Does anybody know how to configure proxy for gsutil?
>
>
>
> I have following set,
>
>
>
> $ echo $http_proxy
>
> http://proxy.mydomain.com:8080
>
>
>
> $ echo $HTTP_PROXY
>
> http://proxy.mydomain.com:8080
>
>
>
> $ echo $https_proxy
>
> http://proxy.mydomain.com:8080
>
>
>
> $ echo $HTTPS_PROXY
>
> http://proxy.mydomain.com:8080
>
>
>
> $ git config --global --get http.proxy
>
> http://proxy.mydomain.com:8080
>
>
>
> I am still getting the same error (http://collabedit.com/vetyg) from
> gsutil. For system info, please have a look at previous email.
>
>
>
> Thanks,
>
> Atiq
>
>
>
> *From:* v8-dev@googlegroups.com [mailto:v8-dev@googlegroups.com] *On
> Behalf Of *Atiq
> *Sent:* Wednesday, June 22, 2016 2:15 PM
> *To:* v8-dev@googlegroups.com
> *Subject:* RE: [v8-dev] fetch failing on recently released Fedora 24
>
>
>
> It seems like a proxy error actually (happening across all Linux Machines
> in this network). I have applied that command manually. Output of that is
> here: http://collabedit.com/vetyg
>
>
>
> It did succeed on Fedora 20 on my notebook which is connected to a
> different network (the network does not require proxy settings)
>
>
>
>
>
> *From:* v8-dev@googlegroups.com [mailto:v8-dev@googlegroups.com
> ] *On Behalf Of *Jochen Eisinger
>
>
> *Sent:* Wednesday, June 22, 2016 1:14 AM
> *To:*
>
> v8-dev@googlegroups.com
>
>
> *Subject:* Re: [v8-dev] fetch failing on recently released Fedora 24
>
>
>
> Do you get a more detailed error when you run the
> download_from_google_storage command manually?
>
> It's failing to download clang-format btw. If you don't want to use clang
> to compile you'll need to set the environment variable GYP_DEFINES to
> clang=0
>
>
>
> Atiq Rahman > schrieb am Mi., 22. Juni
> 2016, 01:40:
>
> Hi,
>
> Fedora 24 has been released today. Apparently, clang binaries for this new
> platform is not there yet. It is throwing following error when `fetch` is
> run,
>
>
>
> $ fetch v8
>
> Running: gclient root
>
> Running: gclient config --spec 'solutions = [
>
>   {
>
> "managed": False,
>
> "name": "v8",
>
> "url": "https://chromium.googlesource.com/v8/v8.git";,
>
> "custom_deps": {},
>
> "deps_file": "DEPS",
>
> "safesync_url": "",
>
>   },
>
> ]
>
> '
>
> Running: gclient sync --with_branch_heads
>
> Error: Command 'download_from_google_storage --no_resume --platform=linux*
> --no_auth --bucket chromium-clang-format -s
> v8/buildtools/linux64/clang-format.sha1' returned non-zero exit status 1 in
> /home/atiq/jv8_ws
>
> Traceback (most recent call last):
>
>   File "/home/atiq/depot_tools/fetch.py", line 353, in 
>
> sys.exit(main())
>
>   File "/home/atiq/depot_tools/fetch.py", line 348, in main
>
> return run(options, spec, root)
>
>   File "/home/atiq/depot_tools/fetch.py", line 342, in run
>
> return checkout.init()
>
>   File "/home/atiq/depot_tools/fetch.py", line 142, in init
>
> self.run_gclient(*sync_cmd)
>
>   File "/home/atiq/depot_tools/fetch.py", line 76, in run_gclient
>
> return self.run(cmd_prefix + cmd, **kwargs)
>
>   File "/home/atiq/depot_tools/fetch.py", line 66, in run
>
> return subprocess.check_output(cmd, **kwargs)
>
>   File "/usr/lib64/python2.7/subprocess.py", line 573, in check_output
>
> raise CalledProcessError(retcode, cmd, output=output)
>
> subprocess.CalledProcessError: Command '('gclient', 'sync',
> '--with_branch_h

Re: [v8-dev] Patch release of the 3.14 branch

[Jochen Eisinger]

I'd recommend including your own version of V8 instead of relying on
whatever the OS provides. That also allows you to keep upgrading the
version of V8 whenever new stability or security fixes are released.

best
-jochen

On Fri, Jul 1, 2016 at 9:06 AM Michael Hablich  wrote:

> Hi Jeroen,
>
> answers inline.
>
> On Friday, July 1, 2016 at 12:51:49 AM UTC+2, Jeroen Ooms wrote:
>
>> On Thu, Jun 30, 2016 at 9:41 PM, Yang Guo  wrote:
>> > May I ask you what your use cases are? What are the security
>> requirements? How serious are information leaks, code execution
>> vulnerabilities etc?
>>
>> As application developer, my main concern is simply to meet the
>> requirements for distributions to keep shipping this version so that
>> our applications remain supported. I think this mainly involves fixing
>> gcc 5/6, and (for debian) mips / ppc. Perhaps also the dead gyp
>> dependency url in the build script which is now 404. For our
>> applications security is not an issue but I suppose every CVE patch is
>> an improvement over the status quo for most distros.
>>
>> > I'm also against merging fixes to the 3.14 branch on the official V8
>> repository. That would give it an appearance of being maintained and
>> secure, while it certainly is not.
>>
>> That is understandable. Perhaps we can find a form to release in a way
>> that emphasizes this branch is legacy/deprecated, yet still shows this
>> is a serious effort to fix urgent problems and has been reviewed, such
>> that downstream maintainers can find and trust it? Maybe a branch repo
>> named '3.14-legacy-unsupported' or so? I am afraid that if I release
>> this under my personal name it probably be ignored :-)
>>
>
> Creating your own fork and maintaining it should be the way to go.
> Currently all the release branches on the V8 repo are tested to a certain
> degree up until the point they got abandoned. When new patches land on
> abandoned branches we cannot test those patches anymore because our infra
> evolves heavily too. This means your requirement "... and trust it." would
> not be met.
>
>
>>
>> > We are recently starting to cooperate with node.js on their LTS branch,
>> so the 5.1 branch will likely receive security fixes for quite some time.
>>
>> That is great to hear. Does that mean the API will be stable?
>
>
> Likely, because Node wants to keep ABI compatibility AFAIK. Please keep in
> mind that the we are talking about a Node.js LTS release. V8 is currently
> *not* offering an LTS release. We are simply trying to help Node with
> theirs.
>
>
>> It would
>> be great if this would be communicated or coordinated with downstream
>> libv8 maintainers. For example Fedora seems to be planning to jump to
>> 5.2.258 which is not LTS I suppose?
>
>
> 5.1 (+Node.js relevant patches and features) is going to be in the next
> Node.js LTS. I would suggest you get in contact with the Node.js LTS WG
> <https://github.com/nodejs/LTS>. They should know best what their plans
> are.
>
>
>> As an application developer I want
>> to encourage the various distributions to agree on which version of
>> the v8 api they want to support so that we can write software that
>> works across platforms.
>>
>> Still it would be really great if we can patch up 3.14 to keep it
>> working at least until this new LTS release is stable and has landed
>> in most distributions.
>>
>> > Aside from that, how likely is it for distros to pick up updates to
>> 3.14 in a timely manner?
>>
>> Assuming patches introduce no breaking changes, I expect they might be
>> adopted easily, especially if they fix urgent problems with gcc 5/6
>> which most distributions will need.
>>
>
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] fetch failing on recently released Fedora 24

[Jochen Eisinger]

AFAIK gsutil respects that boto config file:
https://cloud.google.com/storage/docs/boto-gsutil#config

On Sat, Jun 25, 2016 at 1:55 AM Atiq Rahman  wrote:

> Does anybody know how to configure proxy for gsutil?
>
>
>
> I have following set,
>
>
>
> $ echo $http_proxy
>
> http://proxy.mydomain.com:8080
>
>
>
> $ echo $HTTP_PROXY
>
> http://proxy.mydomain.com:8080
>
>
>
> $ echo $https_proxy
>
> http://proxy.mydomain.com:8080
>
>
>
> $ echo $HTTPS_PROXY
>
> http://proxy.mydomain.com:8080
>
>
>
> $ git config --global --get http.proxy
>
> http://proxy.mydomain.com:8080
>
>
>
> I am still getting the same error (http://collabedit.com/vetyg) from
> gsutil. For system info, please have a look at previous email.
>
>
>
> Thanks,
>
> Atiq
>
>
>
> *From:* v8-dev@googlegroups.com [mailto:v8-dev@googlegroups.com] *On
> Behalf Of *Atiq
> *Sent:* Wednesday, June 22, 2016 2:15 PM
> *To:* v8-dev@googlegroups.com
> *Subject:* RE: [v8-dev] fetch failing on recently released Fedora 24
>
>
>
> It seems like a proxy error actually (happening across all Linux Machines
> in this network). I have applied that command manually. Output of that is
> here: http://collabedit.com/vetyg
>
>
>
> It did succeed on Fedora 20 on my notebook which is connected to a
> different network (the network does not require proxy settings)
>
>
>
>
>
> *From:* v8-dev@googlegroups.com [mailto:v8-dev@googlegroups.com
> ] *On Behalf Of *Jochen Eisinger
>
>
> *Sent:* Wednesday, June 22, 2016 1:14 AM
> *To:*
>
> v8-dev@googlegroups.com
>
>
> *Subject:* Re: [v8-dev] fetch failing on recently released Fedora 24
>
>
>
> Do you get a more detailed error when you run the
> download_from_google_storage command manually?
>
> It's failing to download clang-format btw. If you don't want to use clang
> to compile you'll need to set the environment variable GYP_DEFINES to
> clang=0
>
>
>
> Atiq Rahman > schrieb am Mi., 22. Juni
> 2016, 01:40:
>
> Hi,
>
> Fedora 24 has been released today. Apparently, clang binaries for this new
> platform is not there yet. It is throwing following error when `fetch` is
> run,
>
>
>
> $ fetch v8
>
> Running: gclient root
>
> Running: gclient config --spec 'solutions = [
>
>   {
>
> "managed": False,
>
> "name": "v8",
>
> "url": "https://chromium.googlesource.com/v8/v8.git";,
>
> "custom_deps": {},
>
> "deps_file": "DEPS",
>
> "safesync_url": "",
>
>   },
>
> ]
>
> '
>
> Running: gclient sync --with_branch_heads
>
> Error: Command 'download_from_google_storage --no_resume --platform=linux*
> --no_auth --bucket chromium-clang-format -s
> v8/buildtools/linux64/clang-format.sha1' returned non-zero exit status 1 in
> /home/atiq/jv8_ws
>
> Traceback (most recent call last):
>
>   File "/home/atiq/depot_tools/fetch.py", line 353, in 
>
> sys.exit(main())
>
>   File "/home/atiq/depot_tools/fetch.py", line 348, in main
>
> return run(options, spec, root)
>
>   File "/home/atiq/depot_tools/fetch.py", line 342, in run
>
> return checkout.init()
>
>   File "/home/atiq/depot_tools/fetch.py", line 142, in init
>
> self.run_gclient(*sync_cmd)
>
>   File "/home/atiq/depot_tools/fetch.py", line 76, in run_gclient
>
> return self.run(cmd_prefix + cmd, **kwargs)
>
>   File "/home/atiq/depot_tools/fetch.py", line 66, in run
>
> return subprocess.check_output(cmd, **kwargs)
>
>   File "/usr/lib64/python2.7/subprocess.py", line 573, in check_output
>
> raise CalledProcessError(retcode, cmd, output=output)
>
> subprocess.CalledProcessError: Command '('gclient', 'sync',
> '--with_branch_heads')' returned non-zero exit status 2.
>
>
>
> $ g++ --version
>
> g++ (GCC) 6.1.1 20160510 (Red Hat 6.1.1-2)
>
> Copyright (C) 2016 Free Software Foundation, Inc.
>
> This is free software; see the source for copying conditions.  There is NO
>
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
>
> $ uname -a
>
> Linux fedora_ws 4.5.7-300.fc24.x86_64 #1 SMP Wed Jun 8 19:12:45 UTC 2016
> x86_64 x86_64 x86_64 GNU/Linux
>
> $ cat /etc/redhat-release
>
> Fedora release 24 (Twenty Four)
>
>
>
> $ cd ../depot_tools/
>
> $ git rev-parse HEAD
>
> 7400cf0f8448a3173b4e3

Re: [v8-dev] Poor performance in the V8 C++ API functions respnsible for processing strings.

[Jochen Eisinger]

Here are two examples from Blink. For converting a v8 string to a C++
string, we use this method:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/V8StringResource.cpp?rcl=1466579912&l=101
- it checks whether the v8 string already has an external string resource
(i.e. it's actually already a C++ string), and if not, it externalizes it.

For the other direction, we use a cache from C++ strings to v8 strings with
external string resources:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/V8ValueCache.h?rcl=1466579912&l=94

Having said that, we also observe certain patterns where string conversion
shows up high in the profile, and we're working on improving this over time.

hth
-jochen

On Fri, Jun 17, 2016, 4:46 PM  wrote:

> Many thanks for the suggestions, Jochen.
>
> However, I'm not sure that this resolves the issue at the Node.js/V8
> interface.  I did read up on External String resources a while back.  The
> problem, as I understand it, is that strings passed into a C++ method via
> JavaScript will be bona fide JavaScript strings over which I have no
> control.  Besides, I'm not sure how you would create an External String
> resource in the JavaScript environment anyway.  The reverse is true on the
> output side: the JavaScript environment will be expecting the C++ method to
> create a bona fide JavaScript string to pass out as the return value.
>
> Of course feel free to correct my analysis (preferably with an example or
> two!) if there is a way to utilize some other string handling methodology
> which doesn't merely push the same performance issue into a different part
> of the system.
>
> *** I'm still hopeful that the V8 Development team might take a look at
> this as the performance of the standard string handling functions at the
> JS/C++ interface is absolutely dreadful (as my benchmarks show) and will
> negatively impact on anyone creating C++ based add-ons to what is, an
> otherwise, brilliant JS engine. ***
>
> Thanks again,
>
> Chris.
>
>
>
> On Friday, 10 June 2016 09:54:45 UTC+1, Jochen Eisinger wrote:
>
>> Thanks for the detailed analysis, very interesting. Some comments inline:
>>
>> On Fri, Jun 10, 2016 at 10:45 AM  wrote:
>>
>>> Hello,
>>>
>>> * This post is mainly for the attention of any V8 Developers who might
>>> be monitoring this group.  However, all thoughts and suggestions are
>>> welcome!
>>>
>>> First some background.  I'm development an interface to a database
>>> specifically for the Node.js environment.  The database in question can
>>> operate as an embedded entity, so I am using the published Node.js/V8 API
>>> to communicate with it via its own C API.  I acknowledge that this is a
>>> slightly unusual approach in that the interface between JavaScript and
>>> other databases is often created over TCP infrastructure. However, with the
>>> embedded architecture there is, quite understandably, an expectation of
>>> high performance - certainly much higher than what could otherwise be
>>> achieved over TCP.
>>>
>>> The requirement for high performance has led me to spend some time
>>> analyzing the throughput of various aspects of the V8 API.  As a result, I
>>> have found that there is a particular problem/bottleneck in marshaling
>>> string based data between the JavaScript environment and C/C++ - which of
>>> course is an essential part of establishing close-coupled lines of
>>> communication at this level.
>>>
>>> The following simple benchmark illustrates this performance issue.
>>> Basically, I use the following simple Node.js/JavaScript code to call the
>>> 'db.benchmark()' method 10 times and record the time taken.
>>> Although the code implies that a connection to the database is made, no
>>> database is used, or even loaded, in these tests.  The source code to the
>>> various incarnations of the 'db.benchmark()' method are included together
>>> with the timing results obtained.
>>>
>>> JavaScript Benchmark Code:
>>>
>>> var my_database = require('db_api');
>>> var db = new my_database.db_api();
>>> var max = 10;
>>> var d1 = new Date();
>>> var d1_ms = d1.getTime()
>>> console.log("d1: " + d1.toISOString());
>>> for (n = 0; n < max; n ++) {
>>>db.benchmark("Input String");
>>> }
>>> var d2 = new Date();
>>> var d2_ms = d2.getTime()
>>> var diff = Math.abs(d1

Re: [v8-dev] fetch failing on recently released Fedora 24

[Jochen Eisinger]

Do you get a more detailed error when you run the
download_from_google_storage command manually?

It's failing to download clang-format btw. If you don't want to use clang
to compile you'll need to set the environment variable GYP_DEFINES to
clang=0

Atiq Rahman  schrieb am Mi., 22. Juni 2016, 01:40:

> Hi,
>
> Fedora 24 has been released today. Apparently, clang binaries for this new
> platform is not there yet. It is throwing following error when `fetch` is
> run,
>
>
>
> $ fetch v8
>
> Running: gclient root
>
> Running: gclient config --spec 'solutions = [
>
>   {
>
> "managed": False,
>
> "name": "v8",
>
> "url": "https://chromium.googlesource.com/v8/v8.git";,
>
> "custom_deps": {},
>
> "deps_file": "DEPS",
>
> "safesync_url": "",
>
>   },
>
> ]
>
> '
>
> Running: gclient sync --with_branch_heads
>
> Error: Command 'download_from_google_storage --no_resume --platform=linux*
> --no_auth --bucket chromium-clang-format -s
> v8/buildtools/linux64/clang-format.sha1' returned non-zero exit status 1 in
> /home/atiq/jv8_ws
>
> Traceback (most recent call last):
>
>   File "/home/atiq/depot_tools/fetch.py", line 353, in 
>
> sys.exit(main())
>
>   File "/home/atiq/depot_tools/fetch.py", line 348, in main
>
> return run(options, spec, root)
>
>   File "/home/atiq/depot_tools/fetch.py", line 342, in run
>
> return checkout.init()
>
>   File "/home/atiq/depot_tools/fetch.py", line 142, in init
>
> self.run_gclient(*sync_cmd)
>
>   File "/home/atiq/depot_tools/fetch.py", line 76, in run_gclient
>
> return self.run(cmd_prefix + cmd, **kwargs)
>
>   File "/home/atiq/depot_tools/fetch.py", line 66, in run
>
> return subprocess.check_output(cmd, **kwargs)
>
>   File "/usr/lib64/python2.7/subprocess.py", line 573, in check_output
>
> raise CalledProcessError(retcode, cmd, output=output)
>
> subprocess.CalledProcessError: Command '('gclient', 'sync',
> '--with_branch_heads')' returned non-zero exit status 2.
>
>
>
> $ g++ --version
>
> g++ (GCC) 6.1.1 20160510 (Red Hat 6.1.1-2)
>
> Copyright (C) 2016 Free Software Foundation, Inc.
>
> This is free software; see the source for copying conditions.  There is NO
>
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
>
> $ uname -a
>
> Linux fedora_ws 4.5.7-300.fc24.x86_64 #1 SMP Wed Jun 8 19:12:45 UTC 2016
> x86_64 x86_64 x86_64 GNU/Linux
>
> $ cat /etc/redhat-release
>
> Fedora release 24 (Twenty Four)
>
>
>
> $ cd ../depot_tools/
>
> $ git rev-parse HEAD
>
> 7400cf0f8448a3173b4e35de0aa00352c7e7ac82
>
>
>
> Instead of throwing an error for not finding clang precompiled binaries
> should not it default to gcc/g++?
>
>
>
>
>
> Regards,
>
> Atiq
>
>
>
>
> ---
>
> V8 build resources:
>
> v8 build external blog 
>
> v8 build google wiki 
>
>
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Poor performance in the V8 C++ API functions respnsible for processing strings.

[Jochen Eisinger]

Thanks for the detailed analysis, very interesting. Some comments inline:

On Fri, Jun 10, 2016 at 10:45 AM  wrote:

> Hello,
>
> * This post is mainly for the attention of any V8 Developers who might be
> monitoring this group.  However, all thoughts and suggestions are welcome!
>
> First some background.  I'm development an interface to a database
> specifically for the Node.js environment.  The database in question can
> operate as an embedded entity, so I am using the published Node.js/V8 API
> to communicate with it via its own C API.  I acknowledge that this is a
> slightly unusual approach in that the interface between JavaScript and
> other databases is often created over TCP infrastructure. However, with the
> embedded architecture there is, quite understandably, an expectation of
> high performance - certainly much higher than what could otherwise be
> achieved over TCP.
>
> The requirement for high performance has led me to spend some time
> analyzing the throughput of various aspects of the V8 API.  As a result, I
> have found that there is a particular problem/bottleneck in marshaling
> string based data between the JavaScript environment and C/C++ - which of
> course is an essential part of establishing close-coupled lines of
> communication at this level.
>
> The following simple benchmark illustrates this performance issue.
> Basically, I use the following simple Node.js/JavaScript code to call the
> 'db.benchmark()' method 10 times and record the time taken.
> Although the code implies that a connection to the database is made, no
> database is used, or even loaded, in these tests.  The source code to the
> various incarnations of the 'db.benchmark()' method are included together
> with the timing results obtained.
>
> JavaScript Benchmark Code:
>
> var my_database = require('db_api');
> var db = new my_database.db_api();
> var max = 10;
> var d1 = new Date();
> var d1_ms = d1.getTime()
> console.log("d1: " + d1.toISOString());
> for (n = 0; n < max; n ++) {
>db.benchmark("Input String");
> }
> var d2 = new Date();
> var d2_ms = d2.getTime()
> var diff = Math.abs(d1_ms - d2_ms)
> console.log("\nd2: " + d2.toISOString());
> console.log("diff: " + diff + " secs: " + (diff / 1000));
>
>
> First, let’s create a baseline by removing the benchmark from the
> JavaScript code …
>
>//db.benchmark("Input String");
>
> Results:
> d1: 2016-05-16T09:55:01.919Z
> d2: 2016-05-16T09:55:06.589Z
> diff: 4670 secs: 4.67
>
>
> Now let’s create a second baseline by adding a benchmark call that does
> absolutely nothing.  The JavaScript call 'db.benchmark("Input String")' is
> reinstated but the C++ code of the benchmark method does absolutely nothing
> ...
>
>static void benchmark(const FunctionCallbackInfo& args)
>{
>
>   // interact with a database via its C API
>
>   return;
>}
>
> Results:
> d1: 2016-05-16T09:59:18.915Z
> d2: 2016-05-16T09:59:38.933Z
> diff: 20018 secs: 20.018
>
> This tells us that calling a C/C++ method/function that does absolutely
> nothing (no inputs or outputs to process) is moderately expensive on its
> own.
>
>
> Next, let’s accept a single string argument and copy it to a C character
> buffer for use at the database API …
>
>static void Benchmark(const FunctionCallbackInfo& args)
>{
>   char c_input[256];
>   Local input = args[0]->ToString();
>   input->WriteUtf8(c_input);
>
>   // interact with a database via its C API
>
>   return;
>}
>
>
> Results:
> d1: 2016-05-16T10:02:54.355Z
> d2: 2016-05-16T10:04:26.832Z
> diff: 92477 secs: 92.477
>
> We see a significant performance hit in simply marshaling a simple JS
> string into a C buffer.
>
>
> Next, let’s generate an output for JavaScript derived from a string held
> in a C buffer …
>
>static void benchmark(const FunctionCallbackInfo& args)
>{
>   char c_output[256];
>   Isolate* isolate = args.GetIsolate();
>   HandleScope scope(isolate);
>
>   // interact with a database via its C API
>
>   strcpy(c_output, "Output String");
>   Local output = String::NewFromUtf8(isolate, c_output);
>   args.GetReturnValue().Set(output);
>   return;
>}
>
> Results:
> d1: 2016-05-16T10:14:30.399Z
> d2: 2016-05-16T10:17:16.905Z
> diff: 166506 secs: 166.506
>
> Creating a JavaScript string resource from a C buffer is also expensive.
>
>
> Finally, let's put it all together by accepting a string argument and
> returning a string output …
>
>static void benchmark(const FunctionCallbackInfo& args)
>{
>   char c_input[256], c_output[256];
>   Isolate* isolate = args.GetIsolate();
>   HandleScope scope(isolate);
>   Local input = args[0]->ToString();
>   input->WriteUtf8(c_input);
>
>   // interact with a database via its C API
>
>   strcpy(c_output, "Output String");
>   Local output = String::NewFromUtf8(isolate, c_output);
>   args.GetReturnValue().Set(output);
>   return;
>}
>
> R

[v8-dev] Fwd: [blink-dev] ACTION (possibly) REQUIRED: get a new depot_tools checkout

[Jochen Eisinger]

fyi

-- Forwarded message -
From: Aaron Gable 
Date: Di., 31. Mai 2016, 18:24
Subject: [blink-dev] ACTION (possibly) REQUIRED: get a new depot_tools
checkout
To: Chromium-dev , blink-dev <
blink-...@chromium.org>, infra-annou...@chromium.org <
infra-annou...@chromium.org>


As previously announced
,
depot_tools will be switching its source of truth from SVN to Git on *Monday,
June 6th*. That's one week from yesterday. If you still have an SVN
checkout of depot_tools at that time, you will *stop receiving updates*.

Please follow the instructions below to make sure you have a Git copy of
depot_tools:

1) If you're not sure where your depot_tools checkout is, find it:
On *nix:
echo ${PATH//:/\\n} | grep depot_tools
On windows (sorry, don't know how to do nice grepping there):
echo %path:;=&echo.%

2) Go there and see if it is already a Git checkout (it *probably* is):
cd /path/to/depot_tools
cd .git
If that succeeds, congrats, you're done! If that fails, please continue.

3) Get a new, shiny, Git version of depot_tools:
cd ..
git clone https://chromium.googlesource.com/chromium/tools/depot_tools
 depot_tools_new
mv depot_tools depot_tools_old
mv depot_tools_new depot_tools
(use move instead of mv on Windows)

And now you're done! If any of the above instructions don't make sense, or
don't work for you, please follow the more complete instructions here
.

Thanks for your co-operation,
Aaron

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] How does GC work in v8?

[Jochen Eisinger]

There is no low-level description available. You can look at (old) high
level descriptions here:
http://jayconrod.com/posts/55/a-tour-of-v8-garbage-collection and check out
some of our blog posts about new features in the gc on
http://v8project.blogspot.de/ (search for garbage)

On Wed, Apr 27, 2016 at 12:11 PM  wrote:

> Hello all.
>
> I've a question about v8 GC.
> How does it work? I mean, low-level description.
> I can see some instruction in full-codegen-x64.h - like a PushRoot,
> CompareRoot and etc.
> Is it a gc roots?
>
> Thanks for any advice.
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] How to execute external JS file from script in V8

[Jochen Eisinger]

V8 doesn't have support for loading files. To implement this on the C++
side, have a look at the samples/shell.cc that implements a load() method.

best
-jochen

On Wed, Apr 20, 2016 at 10:59 AM  wrote:

> Thanks for your reply,
> To be precise I have written an equivalent function in .js file. Which I
> can call from C++ using V8. But I don't know how to include external JS file
> See the below code snippet
>
> //include("http://cryptojs.altervista.org/api/functions_cryptography.js";);
> function AESEncrypt (PLAINTEXT, KEY, IV)
> {
>
>
> var Crypt = new Crypt();  // constructor
>
> /*** encrypt */
>
> var ciphertext = Crypt.AES.encrypt(PLAINTEXT, KEY);
> // H3fAh9bppeg=xuHy8woEtOfYYI18tLM76A==BKUvKCztSNl8
>
> /*** decrypt */
>var plaintext  = Crypt.AES.decrypt(ciphertext, KEY);
>
> return ciphertext;
> }
>
> AESEncrypt(param1,param2);
>
>
>
>
>
>
> On Wednesday, 20 April 2016 11:56:04 UTC+5, Jochen Eisinger wrote:
>
>> Hey,
>>
>> it's not clear from your question what you're asking.
>>
>> The snippet is actually an HTML snippet, so I'd expect that pasting it
>> into an HTML file an opening in a browser does what you expect it to do?
>>
>> It doesn't look, however, related to V8 development. Please reach out to
>> the authors / maintainers of the crypto library for how to use it.
>>
>> best
>> -jochen
>>
>> On Wed, Apr 20, 2016 at 6:52 AM  wrote:
>>
> I need to execute following script which uses crypto-js library in V8. How
>>> should I write my js file.
>>>
>>> http://cryptojs.altervista.org/api/functions_cryptography.js"</a>;>
>>>
>>> 
>>>
>>> var Crypt = new Crypt();  // constructor
>>>
>>> /*** encrypt */
>>> var ciphertext = Crypt.AES.encrypt("plaintext", "Secret Passphrase");
>>> // H3fAh9bppeg=xuHy8woEtOfYYI18tLM76A==BKUvKCztSNl8
>>>
>>> /*** decrypt */
>>> var plaintext  = Crypt.AES.decrypt(ciphertext, "Secret Passphrase");
>>>
>>> 
>>>
>>> --
>>> --
>>> 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+un...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] How can I test my own port v8 engine with small example?

[Jochen Eisinger]

Hey,

I don't think dropping the JS dependencies will significantly drop the
required operations for the assembly backend. You could disable the
optimizing compilers (--noopt) and compile without a snapshot and see how
far you can get there, but in general, porting v8 to another architecture
is a significant piece of work, and I don't know of any short cuts.

best
-jochen

On Wed, Apr 20, 2016 at 1:26 PM  wrote:

> Hello guys.
>
> I'm writing my own port v8 engine with exotic architecture.
> As I can see in code v8 load a lot of built-in js files:
> array-iterator.js array.js arraybuffer.js collection-iterator.js
> collection.js generator.js harmony-atomics.js harmony-object-observe.js
> harmony-regexp.js harmony-sharedarraybuffer.js harmony-simd.js
> harmony-species.js harmony-unicode-regexps.js i18n.js iterator-prototype.js
> json.js macros.py math.js messages.jsobject-observe.js prologue.js
> promise-extra.js promise.js proxy.js regexp.js runtime.js spread.js
> string-iterator.js string.js symbol.js templates.js typedarray.js uri.js
> v8natives.js weak-collection.js.
>
> I want to test my own hello world example and I don't want implement
> macroassembler for all operations.
> How can I reduce or remove few of this .js dependencies?
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] How to execute external JS file from script in V8

[Jochen Eisinger]

Hey,

it's not clear from your question what you're asking.

The snippet is actually an HTML snippet, so I'd expect that pasting it into
an HTML file an opening in a browser does what you expect it to do?

It doesn't look, however, related to V8 development. Please reach out to
the authors / maintainers of the crypto library for how to use it.

best
-jochen

On Wed, Apr 20, 2016 at 6:52 AM  wrote:

> I need to execute following script which uses crypto-js library in V8. How
> should I write my js file.
>
> http://cryptojs.altervista.org/api/functions_cryptography.js"</a>;>
> 
>
> var Crypt = new Crypt();  // constructor
>
> /*** encrypt */
> var ciphertext = Crypt.AES.encrypt("plaintext", "Secret Passphrase");
> // H3fAh9bppeg=xuHy8woEtOfYYI18tLM76A==BKUvKCztSNl8
>
> /*** decrypt */
> var plaintext  = Crypt.AES.decrypt(ciphertext, "Secret Passphrase");
>
> 
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Did something change in V8 46 (from 45) that would cause weak references to behave differently?

[Jochen Eisinger]

The old API used to notify you when the object was no longer strongly
referenced. The new API notifies you when the object is no longer alive.

The CL you're pointing to does not affect that behavior - afaik node
doesn't use these gc callbacks, and node-weak certainly does not.

The new API has two callbacks:

the first pass callback comes in after the object was GC'd. At this point,
there might be multiple persistent handles in the system pointing at GC'd
objects, so it's very unsafe to dereference them. The first pass callback
should only clear the persistent handle it was registered for and then
return to V8.

If additional work needs to be done, such as triggering something or
cleaning up C++ side code, a second pass callback can be registered. The
second pass callback is called at some point after all first pass callbacks
where executed and it's safe again to dereference any persistent handle
still alive. the second pass callback might very well get invoked after
further JS execution happened.

hth
-jochen



On Wed, Apr 13, 2016 at 9:14 PM  wrote:

> Just for clarification: the new callback (the one that takes a
> WeakCallbackInfo) functions as follows:
>
> - is called if registered for every GCed weak object
> - is called at the end of a GC run but before any JS execution happens.
> Especially this one is not clear to me from the documentation.
>
> Thanks
>
> Dirk
>
>
> Am Dienstag, 12. April 2016 20:22:25 UTC+2 schrieb Jochen Eisinger:
>
>> ok, so the update to NAN 2.0 broke the node-weak module. Using the
>> kParameter weakness type means that the weak callback will come after the
>> object was already GC'd, and it's no longer safe to access the object in
>> the callback.
>>
>> In fact, the requirement for the callback is that it doesn't invoke any
>> function in the VM but resets the persistent handle. If you need to do any
>> post-processing, you can register a second-pass callback that will be
>> invoked later when it's again safe to call into v8.
>>
>> If you require the old behavior of getting a pointer to object before it
>> dies, you have to rely on the deprecated SetWeak methods (I guess we should
>> consider undeprecating it...)
>>
>> On Tue, Apr 12, 2016 at 8:11 PM  wrote:
>>
>>> Evaluating callback on that stack: 0x5a738dc0
>>> {weakref.node!Nan::imp::FunctionCallbackWrapper(const
>>> v8::FunctionCallbackInfo &)}
>>>
>>> On Tuesday, April 12, 2016 at 7:48:11 PM UTC+2, Jochen Eisinger wrote:
>>>
>>>> What function is "callback" in the HandleApiCallHelper frame pointing
>>>> to?
>>>>
>>>> On Tue, Apr 12, 2016, 7:36 PM  wrote:
>>>>
>>>>> I should have mentioned my original bug report against V8:
>>>>> https://bugs.chromium.org/p/v8/issues/detail?id=4830
>>>>>
>>>>> The stacktrace (with node running in debug mode) would be:
>>>>> https://gist.github.com/bpasero/fb5f8a6022b37f7b1a34
>>>>>
>>>>> I am sitting in the Visual Studio debugger right at the FAIL call and
>>>>> can examine the object. Typing "this" just returns that it is a
>>>>> v8::internal::Object with a value of 0x0baffedf {...}
>>>>>
>>>>> Btw I am able to run IsOddball() and that returns false.
>>>>>
>>>>> On Tuesday, April 12, 2016 at 7:31:23 PM UTC+2, Jochen Eisinger wrote:
>>>>>
>>>>>> and the value of "this" when you hit the FATAL()
>>>>>>
>>>>>> On Tue, Apr 12, 2016 at 7:33 PM Jochen Eisinger 
>>>>>> wrote:
>>>>>>
>>>>> Could you post a stack trace that leads to the FATAL()?
>>>>>>>
>>>>>>> On Tue, Apr 12, 2016 at 7:27 PM Ben Noordhuis 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Tue, Apr 12, 2016 at 7:11 PM,   wrote:
>>>>>>>> > Hi,
>>>>>>>> >
>>>>>>>> > we (Microsoft VS Code team) are tracking down a very weird native
>>>>>>>> crash in
>>>>>>>> > our use of node.js (5.10.0, V8 46) that only ever shows up since
>>>>>>>> we updated
>>>>>>>> > from node.js 4.x (V8 45). It seems that changes (around the
>>>>>>>> Garbace
>>>>>>>> > Collector?) in V8 46 have an impact to the crash.
>>>>>>>> >
>>>>>>>> >

Re: [v8-dev] Did something change in V8 46 (from 45) that would cause weak references to behave differently?

[Jochen Eisinger]

maybe you just got lucky before? The API didn't change for a while now, you
can always check bit.ly/v8-api-changes for updates

Anyways, you get the old behavior by using the SetWeak methods that take a
WebCallbackData (instead of ...Info), i.e.,
https://code.google.com/p/chromium/codesearch#chromium/src/v8/include/v8.h&l=564

On Tue, Apr 12, 2016 at 8:26 PM  wrote:

> We were using NAN 2.x before with node-weak and node.js 4.x without this
> issue so I assume that the V8 update to 46 alters the behaviour of the
> callback passed into the SetWeak method.
>
> Can you clarify how I would be able to get the old behaviour back by
> changing the node-weak module?
>
>
> On Tuesday, April 12, 2016 at 8:22:25 PM UTC+2, Jochen Eisinger wrote:
>
>> ok, so the update to NAN 2.0 broke the node-weak module. Using the
>> kParameter weakness type means that the weak callback will come after the
>> object was already GC'd, and it's no longer safe to access the object in
>> the callback.
>>
>> In fact, the requirement for the callback is that it doesn't invoke any
>> function in the VM but resets the persistent handle. If you need to do any
>> post-processing, you can register a second-pass callback that will be
>> invoked later when it's again safe to call into v8.
>>
>> If you require the old behavior of getting a pointer to object before it
>> dies, you have to rely on the deprecated SetWeak methods (I guess we should
>> consider undeprecating it...)
>>
>> On Tue, Apr 12, 2016 at 8:11 PM  wrote:
>>
>>> Evaluating callback on that stack: 0x5a738dc0
>>> {weakref.node!Nan::imp::FunctionCallbackWrapper(const
>>> v8::FunctionCallbackInfo &)}
>>>
>>> On Tuesday, April 12, 2016 at 7:48:11 PM UTC+2, Jochen Eisinger wrote:
>>>
>>>> What function is "callback" in the HandleApiCallHelper frame pointing
>>>> to?
>>>>
>>>> On Tue, Apr 12, 2016, 7:36 PM  wrote:
>>>>
>>>>> I should have mentioned my original bug report against V8:
>>>>> https://bugs.chromium.org/p/v8/issues/detail?id=4830
>>>>>
>>>>> The stacktrace (with node running in debug mode) would be:
>>>>> https://gist.github.com/bpasero/fb5f8a6022b37f7b1a34
>>>>>
>>>>> I am sitting in the Visual Studio debugger right at the FAIL call and
>>>>> can examine the object. Typing "this" just returns that it is a
>>>>> v8::internal::Object with a value of 0x0baffedf {...}
>>>>>
>>>>> Btw I am able to run IsOddball() and that returns false.
>>>>>
>>>>> On Tuesday, April 12, 2016 at 7:31:23 PM UTC+2, Jochen Eisinger wrote:
>>>>>
>>>>>> and the value of "this" when you hit the FATAL()
>>>>>>
>>>>>> On Tue, Apr 12, 2016 at 7:33 PM Jochen Eisinger 
>>>>>> wrote:
>>>>>>
>>>>> Could you post a stack trace that leads to the FATAL()?
>>>>>>>
>>>>>>> On Tue, Apr 12, 2016 at 7:27 PM Ben Noordhuis 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Tue, Apr 12, 2016 at 7:11 PM,   wrote:
>>>>>>>> > Hi,
>>>>>>>> >
>>>>>>>> > we (Microsoft VS Code team) are tracking down a very weird native
>>>>>>>> crash in
>>>>>>>> > our use of node.js (5.10.0, V8 46) that only ever shows up since
>>>>>>>> we updated
>>>>>>>> > from node.js 4.x (V8 45). It seems that changes (around the
>>>>>>>> Garbace
>>>>>>>> > Collector?) in V8 46 have an impact to the crash.
>>>>>>>> >
>>>>>>>> > Specifically, we are using the node-weak module
>>>>>>>> > (https://github.com/TooTallNate/node-weak) to be able to get
>>>>>>>> weak references
>>>>>>>> > onto JavaScript objects. This used to work relatively good in
>>>>>>>> node.js 4.x,
>>>>>>>> > but with node.js 5.x we suddenly get the entire node.js program
>>>>>>>> to terminate
>>>>>>>> > with a fatal crash.
>>>>>>>> >
>>>>>>>> > Today we were finally able to track the location of where the
>>>>>>>> crash
>>>>>>>> &

Re: [v8-dev] Did something change in V8 46 (from 45) that would cause weak references to behave differently?

[Jochen Eisinger]

ok, so the update to NAN 2.0 broke the node-weak module. Using the
kParameter weakness type means that the weak callback will come after the
object was already GC'd, and it's no longer safe to access the object in
the callback.

In fact, the requirement for the callback is that it doesn't invoke any
function in the VM but resets the persistent handle. If you need to do any
post-processing, you can register a second-pass callback that will be
invoked later when it's again safe to call into v8.

If you require the old behavior of getting a pointer to object before it
dies, you have to rely on the deprecated SetWeak methods (I guess we should
consider undeprecating it...)

On Tue, Apr 12, 2016 at 8:11 PM  wrote:

> Evaluating callback on that stack: 0x5a738dc0
> {weakref.node!Nan::imp::FunctionCallbackWrapper(const
> v8::FunctionCallbackInfo &)}
>
> On Tuesday, April 12, 2016 at 7:48:11 PM UTC+2, Jochen Eisinger wrote:
>
>> What function is "callback" in the HandleApiCallHelper frame pointing to?
>>
>> On Tue, Apr 12, 2016, 7:36 PM  wrote:
>>
>>> I should have mentioned my original bug report against V8:
>>> https://bugs.chromium.org/p/v8/issues/detail?id=4830
>>>
>>> The stacktrace (with node running in debug mode) would be:
>>> https://gist.github.com/bpasero/fb5f8a6022b37f7b1a34
>>>
>>> I am sitting in the Visual Studio debugger right at the FAIL call and
>>> can examine the object. Typing "this" just returns that it is a
>>> v8::internal::Object with a value of 0x0baffedf {...}
>>>
>>> Btw I am able to run IsOddball() and that returns false.
>>>
>>> On Tuesday, April 12, 2016 at 7:31:23 PM UTC+2, Jochen Eisinger wrote:
>>>
>>>> and the value of "this" when you hit the FATAL()
>>>>
>>>> On Tue, Apr 12, 2016 at 7:33 PM Jochen Eisinger 
>>>> wrote:
>>>>
>>> Could you post a stack trace that leads to the FATAL()?
>>>>>
>>>>> On Tue, Apr 12, 2016 at 7:27 PM Ben Noordhuis 
>>>>> wrote:
>>>>>
>>>>>> On Tue, Apr 12, 2016 at 7:11 PM,   wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > we (Microsoft VS Code team) are tracking down a very weird native
>>>>>> crash in
>>>>>> > our use of node.js (5.10.0, V8 46) that only ever shows up since we
>>>>>> updated
>>>>>> > from node.js 4.x (V8 45). It seems that changes (around the Garbace
>>>>>> > Collector?) in V8 46 have an impact to the crash.
>>>>>> >
>>>>>> > Specifically, we are using the node-weak module
>>>>>> > (https://github.com/TooTallNate/node-weak) to be able to get weak
>>>>>> references
>>>>>> > onto JavaScript objects. This used to work relatively good in
>>>>>> node.js 4.x,
>>>>>> > but with node.js 5.x we suddenly get the entire node.js program to
>>>>>> terminate
>>>>>> > with a fatal crash.
>>>>>> >
>>>>>> > Today we were finally able to track the location of where the crash
>>>>>> > originates and it seems to happen when our application simply calls
>>>>>> into a
>>>>>> > property of the object that is weakly referenced. This call at one
>>>>>> point
>>>>>> > reaches the following assertion:
>>>>>> >
>>>>>> > void Object::VerifyApiCallResultType() {
>>>>>> > #if DEBUG
>>>>>> >   if (!(IsSmi() || IsString() || IsSymbol() || IsSpecObject() ||
>>>>>> > IsHeapNumber() || IsSimd128Value() || IsUndefined() ||
>>>>>> IsTrue() ||
>>>>>> > IsFalse() || IsNull())) {
>>>>>> > FATAL("API call returned invalid object");
>>>>>> >   }
>>>>>> > #endif  // DEBUG
>>>>>> > }
>>>>>> >
>>>>>> >
>>>>>> > The process terminates from the FATAL call, as none of the previous
>>>>>> checks
>>>>>> > in this method hold.
>>>>>> >
>>>>>> >
>>>>>> > Now, the interesting question is: How would it be possible to have
>>>>>> a JS
>>>>>> > object where calling properties on it would fail in

Re: [v8-dev] Did something change in V8 46 (from 45) that would cause weak references to behave differently?

[Jochen Eisinger]

What function is "callback" in the HandleApiCallHelper frame pointing to?

On Tue, Apr 12, 2016, 7:36 PM  wrote:

> I should have mentioned my original bug report against V8:
> https://bugs.chromium.org/p/v8/issues/detail?id=4830
>
> The stacktrace (with node running in debug mode) would be:
> https://gist.github.com/bpasero/fb5f8a6022b37f7b1a34
>
> I am sitting in the Visual Studio debugger right at the FAIL call and can
> examine the object. Typing "this" just returns that it is a
> v8::internal::Object with a value of 0x0baffedf {...}
>
> Btw I am able to run IsOddball() and that returns false.
>
> On Tuesday, April 12, 2016 at 7:31:23 PM UTC+2, Jochen Eisinger wrote:
>
>> and the value of "this" when you hit the FATAL()
>>
>> On Tue, Apr 12, 2016 at 7:33 PM Jochen Eisinger 
>> wrote:
>>
> Could you post a stack trace that leads to the FATAL()?
>>>
>>> On Tue, Apr 12, 2016 at 7:27 PM Ben Noordhuis 
>>> wrote:
>>>
>>>> On Tue, Apr 12, 2016 at 7:11 PM,   wrote:
>>>> > Hi,
>>>> >
>>>> > we (Microsoft VS Code team) are tracking down a very weird native
>>>> crash in
>>>> > our use of node.js (5.10.0, V8 46) that only ever shows up since we
>>>> updated
>>>> > from node.js 4.x (V8 45). It seems that changes (around the Garbace
>>>> > Collector?) in V8 46 have an impact to the crash.
>>>> >
>>>> > Specifically, we are using the node-weak module
>>>> > (https://github.com/TooTallNate/node-weak) to be able to get weak
>>>> references
>>>> > onto JavaScript objects. This used to work relatively good in node.js
>>>> 4.x,
>>>> > but with node.js 5.x we suddenly get the entire node.js program to
>>>> terminate
>>>> > with a fatal crash.
>>>> >
>>>> > Today we were finally able to track the location of where the crash
>>>> > originates and it seems to happen when our application simply calls
>>>> into a
>>>> > property of the object that is weakly referenced. This call at one
>>>> point
>>>> > reaches the following assertion:
>>>> >
>>>> > void Object::VerifyApiCallResultType() {
>>>> > #if DEBUG
>>>> >   if (!(IsSmi() || IsString() || IsSymbol() || IsSpecObject() ||
>>>> > IsHeapNumber() || IsSimd128Value() || IsUndefined() ||
>>>> IsTrue() ||
>>>> > IsFalse() || IsNull())) {
>>>> > FATAL("API call returned invalid object");
>>>> >   }
>>>> > #endif  // DEBUG
>>>> > }
>>>> >
>>>> >
>>>> > The process terminates from the FATAL call, as none of the previous
>>>> checks
>>>> > in this method hold.
>>>> >
>>>> >
>>>> > Now, the interesting question is: How would it be possible to have a
>>>> JS
>>>> > object where calling properties on it would fail in such a fatal way?
>>>> It
>>>> > seems to us that the object we are calling a property on is a pointer
>>>> to a
>>>> > location in memory where no V8 object exists anymore. It almost seems
>>>> that
>>>> > the object was garbage collected (or moved to another address?)
>>>> without the
>>>> > JS side (or more specifically the node-weak side) getting to know.
>>>> >
>>>> >
>>>> > Since this only reproduces with using node-weak, it seems very likely
>>>> that
>>>> > there is an issue with either node-weak or NAN. In fact, node-weak is
>>>> > calling into SetWeak()
>>>> > (
>>>> https://github.com/TooTallNate/node-weak/blob/master/src/weakref.cc#L174
>>>> )
>>>> > and relies on the fact that the callback passed in is triggered and
>>>> maybe
>>>> > this callback is not triggered anymore in a sync fashion but rather
>>>> async?
>>>> >
>>>> >
>>>> > I would appreciate some pointers if there is something that could have
>>>> > probably changed in V8 46 that could have an impact on this.
>>>>
>>>> If you have a simple test case (stress on 'simple'), I'll have a look.
>>>>
>>>> --
>>>> --
>>>> 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+un...@googlegroups.com.
>>>
>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Did something change in V8 46 (from 45) that would cause weak references to behave differently?

[Jochen Eisinger]

and the value of "this" when you hit the FATAL()

On Tue, Apr 12, 2016 at 7:33 PM Jochen Eisinger  wrote:

> Could you post a stack trace that leads to the FATAL()?
>
> On Tue, Apr 12, 2016 at 7:27 PM Ben Noordhuis  wrote:
>
>> On Tue, Apr 12, 2016 at 7:11 PM,   wrote:
>> > Hi,
>> >
>> > we (Microsoft VS Code team) are tracking down a very weird native crash
>> in
>> > our use of node.js (5.10.0, V8 46) that only ever shows up since we
>> updated
>> > from node.js 4.x (V8 45). It seems that changes (around the Garbace
>> > Collector?) in V8 46 have an impact to the crash.
>> >
>> > Specifically, we are using the node-weak module
>> > (https://github.com/TooTallNate/node-weak) to be able to get weak
>> references
>> > onto JavaScript objects. This used to work relatively good in node.js
>> 4.x,
>> > but with node.js 5.x we suddenly get the entire node.js program to
>> terminate
>> > with a fatal crash.
>> >
>> > Today we were finally able to track the location of where the crash
>> > originates and it seems to happen when our application simply calls
>> into a
>> > property of the object that is weakly referenced. This call at one point
>> > reaches the following assertion:
>> >
>> > void Object::VerifyApiCallResultType() {
>> > #if DEBUG
>> >   if (!(IsSmi() || IsString() || IsSymbol() || IsSpecObject() ||
>> > IsHeapNumber() || IsSimd128Value() || IsUndefined() || IsTrue()
>> ||
>> > IsFalse() || IsNull())) {
>> > FATAL("API call returned invalid object");
>> >   }
>> > #endif  // DEBUG
>> > }
>> >
>> >
>> > The process terminates from the FATAL call, as none of the previous
>> checks
>> > in this method hold.
>> >
>> >
>> > Now, the interesting question is: How would it be possible to have a JS
>> > object where calling properties on it would fail in such a fatal way? It
>> > seems to us that the object we are calling a property on is a pointer
>> to a
>> > location in memory where no V8 object exists anymore. It almost seems
>> that
>> > the object was garbage collected (or moved to another address?) without
>> the
>> > JS side (or more specifically the node-weak side) getting to know.
>> >
>> >
>> > Since this only reproduces with using node-weak, it seems very likely
>> that
>> > there is an issue with either node-weak or NAN. In fact, node-weak is
>> > calling into SetWeak()
>> > (
>> https://github.com/TooTallNate/node-weak/blob/master/src/weakref.cc#L174)
>> > and relies on the fact that the callback passed in is triggered and
>> maybe
>> > this callback is not triggered anymore in a sync fashion but rather
>> async?
>> >
>> >
>> > I would appreciate some pointers if there is something that could have
>> > probably changed in V8 46 that could have an impact on this.
>>
>> If you have a simple test case (stress on 'simple'), I'll have a look.
>>
>> --
>> --
>> v8-dev mailing list
>> v8-dev@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.
>>
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Did something change in V8 46 (from 45) that would cause weak references to behave differently?

[Jochen Eisinger]

Could you post a stack trace that leads to the FATAL()?

On Tue, Apr 12, 2016 at 7:27 PM Ben Noordhuis  wrote:

> On Tue, Apr 12, 2016 at 7:11 PM,   wrote:
> > Hi,
> >
> > we (Microsoft VS Code team) are tracking down a very weird native crash
> in
> > our use of node.js (5.10.0, V8 46) that only ever shows up since we
> updated
> > from node.js 4.x (V8 45). It seems that changes (around the Garbace
> > Collector?) in V8 46 have an impact to the crash.
> >
> > Specifically, we are using the node-weak module
> > (https://github.com/TooTallNate/node-weak) to be able to get weak
> references
> > onto JavaScript objects. This used to work relatively good in node.js
> 4.x,
> > but with node.js 5.x we suddenly get the entire node.js program to
> terminate
> > with a fatal crash.
> >
> > Today we were finally able to track the location of where the crash
> > originates and it seems to happen when our application simply calls into
> a
> > property of the object that is weakly referenced. This call at one point
> > reaches the following assertion:
> >
> > void Object::VerifyApiCallResultType() {
> > #if DEBUG
> >   if (!(IsSmi() || IsString() || IsSymbol() || IsSpecObject() ||
> > IsHeapNumber() || IsSimd128Value() || IsUndefined() || IsTrue()
> ||
> > IsFalse() || IsNull())) {
> > FATAL("API call returned invalid object");
> >   }
> > #endif  // DEBUG
> > }
> >
> >
> > The process terminates from the FATAL call, as none of the previous
> checks
> > in this method hold.
> >
> >
> > Now, the interesting question is: How would it be possible to have a JS
> > object where calling properties on it would fail in such a fatal way? It
> > seems to us that the object we are calling a property on is a pointer to
> a
> > location in memory where no V8 object exists anymore. It almost seems
> that
> > the object was garbage collected (or moved to another address?) without
> the
> > JS side (or more specifically the node-weak side) getting to know.
> >
> >
> > Since this only reproduces with using node-weak, it seems very likely
> that
> > there is an issue with either node-weak or NAN. In fact, node-weak is
> > calling into SetWeak()
> > (
> https://github.com/TooTallNate/node-weak/blob/master/src/weakref.cc#L174)
> > and relies on the fact that the callback passed in is triggered and maybe
> > this callback is not triggered anymore in a sync fashion but rather
> async?
> >
> >
> > I would appreciate some pointers if there is something that could have
> > probably changed in V8 46 that could have an impact on this.
>
> If you have a simple test case (stress on 'simple'), I'll have a look.
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Exposing JSON::Stringify to Blink

[Jochen Eisinger]

oh well, having JSON::Stringify in the C++ API makes sense for V8
regardless.

On Fri, Apr 1, 2016 at 12:13 AM Elliott Sprehn  wrote:

> As I understand it payments wants to say the data you're sending needs to
> be serializable to send over the wire to a payment
> system. SerializedScriptValue is structured clone, which doesn't define a
> wire format and instead is just an algorithm to serialize/deserialize. ex.
> This thing shouldn't allow message ports, array buffers, dates, regexes,
> etc.
>
> On Thu, Mar 31, 2016 at 3:09 PM, Jochen Eisinger 
> wrote:
>
>> Do you plan to support the additional parameters (replacer and gap)?
>> Anyways, feel free to send the CL to me and verwaest@.
>>
>> Out of curiosity, why this odd definition of an object that can be
>> serialized and deserialized instead of the standardized
>> SerializedScriptValue IDL type?
>>
>> On Thu, Mar 31, 2016 at 11:40 PM Rouslan Solomakhin 
>> wrote:
>>
>>> Hi,
>>>
>>> I am planning to expose JSON::Stringify API to Blink, similar to how
>>> JSON::Parse was exposed in https://codereview.chromium.org/21959003/. I
>>> am following the instructions at
>>> https://github.com/v8/v8/wiki/Contributing. This is for
>>> http://crbug.com/587995. Who would be a good code reviewer for this
>>> patch?
>>>
>>> Cheers,
>>> Rouslan
>>>
>>> --
>>> --
>>> v8-dev mailing list
>>> v8-dev@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.
>>>
>>
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Exposing JSON::Stringify to Blink

[Jochen Eisinger]

Do you plan to support the additional parameters (replacer and gap)?
Anyways, feel free to send the CL to me and verwaest@.

Out of curiosity, why this odd definition of an object that can be
serialized and deserialized instead of the standardized
SerializedScriptValue IDL type?

On Thu, Mar 31, 2016 at 11:40 PM Rouslan Solomakhin 
wrote:

> Hi,
>
> I am planning to expose JSON::Stringify API to Blink, similar to how
> JSON::Parse was exposed in https://codereview.chromium.org/21959003/. I
> am following the instructions at
> https://github.com/v8/v8/wiki/Contributing. This is for
> http://crbug.com/587995. Who would be a good code reviewer for this patch?
>
> Cheers,
> Rouslan
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] How to increase JS Heap size limit?

[Jochen Eisinger]

it means that the process ran out of memory. ~3GB sounds like you're
running a 32bit build?

On Tue, Mar 15, 2016 at 5:49 AM  wrote:

> Exactly It fails in committing memory in VirtualAlloc (in file
> platform-win32.cc).
>
> bool VirtualMemory::CommitRegion(void* base, size_t size, bool
> is_executable) {
>   int prot = is_executable ? PAGE_EXECUTE_READWRITE : PAGE_READWRITE;
>   if (NULL == VirtualAlloc(base, size, MEM_COMMIT, prot)) {
> return false;
>   }
>   return true;
> }
>
> Anybody knows whats going wrong here?
>
>
> On Monday, March 14, 2016 at 8:54:43 PM UTC+5:30, tuma...@gmail.com wrote:
>>
>> I tried with --js-flags="--max-old-space-size=1" while launching my
>> app (using CEF).
>>
>> And used below script to check (from
>> https://bugs.chromium.org/p/v8/issues/detail?id=847)
>>
>> (function () {
>>   function tree (n, m) {
>> if (n > 0) {
>>   var a = new Array(m);
>>   for (var i = 0; i < m; i++) a[i] = tree(n - 1, m);
>>   return a;
>> }
>>   }
>>
>>   var trees = [];
>>   while (true) trees.push(tree(15, 2));
>> })();
>>
>>
>> *After some time, the allocation in below line (in src\heap\spaces.cc 
>> PagedSpace::Expand()) fails and render process is crashing (memory usage was 
>> around 3GB +).*
>>
>> **
>>
>>
>> Page* p = heap()->isolate()->memory_allocator()->AllocatePage(size, this,
>> 
>> executable());
>>   if (p == NULL) return false;
>>
>>
>>
>>
>> On Friday, March 11, 2016 at 9:47:29 PM UTC+5:30, Jochen Eisinger wrote:
>>>
>>> Is configuring the size via the ResourceConstraint class not covering
>>> your use case?
>>>
>>> On Fri, Mar 11, 2016, 5:14 PM  wrote:
>>>
>>>> Hi,
>>>>
>>>> We need to increase the V8 heap size limit for certain case. Can some
>>>> one please point me the source code where we can change this limit?
>>>>
>>>> Regards,
>>>> T. Umapathy
>>>>
>>>>
>>>> --
>>>> --
>>>> 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+un...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] CVE-2016-1007, CVE-2016-1009

[Jochen Eisinger]

CVEs are very specific to the product they refer to - usually, they don't
affect other products that don't use the exact product and version
referenced in the CVE.

So, no, V8 is not affected by those two CVEs

Best
Jochen

On Mon, Mar 14, 2016, 12:57 AM Barry Dawson 
wrote:

> Adobe has released updates to fix a security vulnerability CVE-2016-1007,
> CVE-2016-1009:
> https://helpx.adobe.com/security/products/acrobat/apsb16-09.html
>
>
> The vulnerabilities are related to javascript and executing scripts, are
> these vulnerabilities also present in the V8 javascript engine?
>
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-1007
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-1009
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] How to increase JS Heap size limit?

[Jochen Eisinger]

Is configuring the size via the ResourceConstraint class not covering your
use case?

On Fri, Mar 11, 2016, 5:14 PM  wrote:

> Hi,
>
> We need to increase the V8 heap size limit for certain case. Can some one
> please point me the source code where we can change this limit?
>
> Regards,
> T. Umapathy
>
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Build optdebug mode for android build.

[Jochen Eisinger]

Does eg "make android_arm.optdebug" not work for you?

On Fri, Mar 11, 2016 at 10:43 AM  wrote:

> Hi, v8-dev folks.
>
> Regular build, i.e. windows, linux, has 'optdebug' option which compiles
> binary with no compiler optimization(-O0) and leaves symbol info.
> However, build for android doesn't have such option. It just have release,
> debug.
>
> I thinks 'optdebug' option is useful for people who develop V8 for android.
> Is there a reason it doesn't have it? or just missed??
>
> Thanks.
> Myeong-bo Shim.
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Re: Debugging via gdb with possibility see local variables

[Jochen Eisinger]

try "info locals" to see all variables that gdb knows about in the current
context.

This is, however, not v8 specific, I'd recommend reading a tutorial about
gdb or use a graphical frontend such as ddd

On Wed, Mar 9, 2016 at 9:50 AM  wrote:

> Hi, thanks for the answer, but I of course check bt:
>
> It is:
> #0  v8::internal::FullCodeGenerator::Generate() () at
> ../src/full-codegen/x64/full-codegen-x64.cc:94
> #1  0x010240de in
> v8::internal::FullCodeGenerator::MakeCode(v8::internal::CompilationInfo*)
> () at ../src/full-codegen/full-codegen.cc:49
> #2  0x00e8f9dc in
> v8::internal::GenerateBaselineCode(v8::internal::CompilationInfo*) () at
> ../src/compiler.cc:782
> #3  0x00e99026 in
> v8::internal::CompileBaselineCode(v8::internal::CompilationInfo*) () at
> ../src/compiler.cc:796
> #4  0x00e8da38 in
> v8::internal::CompileToplevel(v8::internal::CompilationInfo*) () at
> ../src/compiler.cc:1281
> #5  0x00e8e962 in
> v8::internal::Compiler::CompileScript(v8::internal::Handle,
> v8::internal::Handle, int, int,
> v8::ScriptOriginOptions, v8::internal::Handle,
> v8::internal::Handle, v8::Extension*,
> v8::internal::ScriptData**, v8::ScriptCompiler::CompileOptions,
> v8::internal::NativesFlag, bool) () at ../src/compiler.cc:1510
> #6  0x00cf590f in
> v8::internal::Bootstrapper::CompileNative(v8::internal::Isolate*,
> v8::internal::Vector,
> v8::internal::Handle, int,
> v8::internal::Handle*, v8::internal::NativesFlag) ()
> at ../src/bootstrapper.cc:1889
> #7  0x00cf5c53 in
> v8::internal::Bootstrapper::CompileExperimentalBuiltin(v8::internal::Isolate*,
> int) () at ../src/bootstrapper.cc:1838
> #8  0x00d00ec0 in
> v8::internal::Genesis::InstallExperimentalNatives() () at
> ../src/bootstrapper.cc:2988
> #9  0x00d04094 in
> v8::internal::Genesis::Genesis(v8::internal::Isolate*,
> v8::internal::MaybeHandle,
> v8::Local, v8::ExtensionConfiguration*,
> v8::internal::GlobalContextType) () at ../src/bootstrapper.cc:3589
> #10 0x00ce7684 in
> v8::internal::Bootstrapper::CreateEnvironment(v8::internal::MaybeHandle,
> v8::Local, v8::ExtensionConfiguration*,
> v8::internal::GlobalContextType) () at ../src/bootstrapper.cc:327
> #11 0x00c878af in v8::CreateEnvironment(v8::internal::Isolate*,
> v8::ExtensionConfiguration*, v8::Local,
> v8::Local)
> () at ../src/api.cc:5490
> #12 0x00c60bfc in v8::Context::New(v8::Isolate*,
> v8::ExtensionConfiguration*, v8::Local,
> v8::Local) ()
> at ../src/api.cc:5518
> #13 0x00c313db in v8::Shell::CreateEvaluationContext(v8::Isolate*)
> () at ../src/d8.cc:1268
> #14 0x00c355ad in v8::Shell::RunMain(v8::Isolate*, int, char**,
> bool) () at ../src/d8.cc:2042
> #15 0x00c36801 in v8::Shell::Main(int, char**) () at
> ../src/d8.cc:2521
> #16 0x00c3d092 in main () at ../src/d8.cc:2562
>
> after I've typed first 's', then I've typed 'print info' and received
> 'No symbol "info" in current context' :(
>
> Does gdb work for anyone? Google guys, where are you?
>
> On Friday, March 4, 2016 at 5:42:12 AM UTC+6, m0609...@samsung.com wrote:
>>
>> Hi.
>>
>> I think you couldn't see local variables of 'FullCodeGenerator::Generate'
>> since you are in different function context.
>>
>> You set break point at 'FullCodeGenerator::Generate' and then proceeded
>> program with 's' command.
>> This results in function call and you might be at
>> ''FullCodeGenrator::isolate' which doesn't have "info" as local variable.
>>
>> Have you ever checked backtrace?
>> When I followed your instruction, I get following backtrace.
>>
>> #0  v8::internal::FullCodeGenerator::isolate (this=0x7fffbe28) at
>> .././src/full-codegen/full-codegen.h:703
>> #1  0x014756e7 in v8::internal::FullCodeGenerator::Generate
>> (this=0x7fffbe28) at ../src/full-codegen/x64/full-codegen-x64.cc:94
>> #2  0x01078096 in v8::internal::FullCodeGenerator::MakeCode
>> (info=0x7fffc478) at ../src/full-codegen/full-codegen.cc:51
>> #3  0x00ecc9cc in v8::internal::GenerateBaselineCode
>> (info=0x7fffc478) at ../src/compiler.cc:790
>> #4  0x00ed5636 in v8::internal::CompileBaselineCode
>> (info=0x7fffc478) at ../src/compiler.cc:804
>>
>> Thanks.
>>
>> 2016년 3월 3일 목요일 오후 5시 40분 21초 UTC+9, dima...@gmail.com 님의 말:
>>>
>>> Hi guys.
>>>
>>> I compile v8 with next command:
>>> $ x64.debug debugsymbols=on disassembler=on gdbjit=on console=readline
>>>
>>> then I want to setup a breakpoint on v8::internal::FullCodeGenerator::
>>> Generate() in gdb
>>> I do next steps
>>> $ gdb ./out/x64.debug/d8
>>> $ break v8::internal::FullCodeGenerator::Generate()
>>>
>>> and everythink is ok, and then I run d8 with some small js script
>>>
>>> $ r ../test.js
>>>
>>> and I stop on this line
>>>
>>> CompilationInfo* info = info_;
>>>
>>> $ s
>>> $ s
>>>
>>> And here I want to see what is value of local variable info
>>> I'm typing
>>>
>>> $ p info
>>>
>>> And I'm receiving:
>>>
>>> No symb

Re: [v8-dev] Building on OSX problems

[Jochen Eisinger]

filed https://bugs.chromium.org/p/v8/issues/detail?id=4821 to track this

On Tue, Mar 8, 2016 at 3:04 PM Jochen Eisinger  wrote:

> Yeah, I guess we should invest in updating the tutorial for other OSs as
> well. The set of libraries you have to link against is the same as on
> Linux, however, the command line is different (and I don't know off the top
> of my head how the correct command line for OSX would look like).
>
> On Tue, Mar 8, 2016 at 2:50 PM Frank Lyder Bredland <
> knarfpriv...@gmail.com> wrote:
>
>> Seems like your correct about the tutorial being for Linux, I just
>> assumed that it would be the same for OSX since they are both *nix systems,
>> thats my fault.
>> I however would wish that there also was a Windows and OSX version of the
>> tutorial.
>>
>> Seems like there was a binary in ./out/x64.release/hello-world just as
>> you said. So even if the tutorial was for Linux I guess it worked on OSX?
>>
>> I'd wished that this made me any wiser, but how am I supposed to link
>> this against my own application?
>> I mean, I guess I could just change the hello_world example and keep my
>> whole application in that file, but I guess thats not the best way to
>> develop C++ applications while embedding V8.
>>
>> What I would like to do is in some way build something that I could link
>> against my application.
>>
>> How would I go about doing that?
>> Normally for other libraries you could download the header files and some
>> pre-build libraries for your platform.
>> Since I can't find this option for V8 I'm guessing you have to build from
>> source.
>> Running "make x64.release" worked and I was able to run the hello_world
>> example, so I guess building works.
>>
>> Now how would link against this on OSX? I'm at a bit of a loss, since the
>> example is for Linux and there are no example for OSX.
>>
>> On Tuesday, March 8, 2016 at 2:37:06 PM UTC+1, Jochen Eisinger wrote:
>>
>>>
>>>
>>> On Tue, Mar 8, 2016 at 2:00 PM Frank Lyder Bredland 
>>> wrote:
>>>
>>>> Okay, I'm afraid most of what your saying is gibberish to me.
>>>> It's a bit hard trying to get V8 to work when literally the first
>>>> example doesn't work.
>>>>
>>>
>>>
>>> The tutorial explicitly says that it's targeting Linux...
>>>
>>>
>>>> Could you give me a step-to-step tutorial on how I'm supposed to build
>>>> the hello_world example?
>>>>
>>>
>>> make x64.release is enough to build hello world. it's in
>>> out/x64.release/hello-world
>>>
>>>
>>>>
>>>> What I tried, based on the tutorial (
>>>> https://github.com/v8/v8/wiki/Getting%20Started%20with%20Embedding)
>>>> was the following:
>>>>
>>>> $ fetch v8 # do download v8
>>>> $ git checkout -b 4.8 -t branch-heads/4.8 # to get to the correct
>>>> branch
>>>> $ make x64.release # to build the lib?
>>>>
>>>> And then I copy-pasted the hello_world.cpp file from that page and
>>>> tried to build it using the command that was listed there.
>>>> Which gives me a bunch of errors for missing .a files.
>>>>
>>>> So my question is this:
>>>>
>>>> Can you explain it to me like I'm five, how to I build and run this
>>>> hello_world.cpp example on OSX using make and gyp or whatever?
>>>> If the example is outdated then how am I supposed to do it?
>>>>
>>>
>>> The example assumes you use Linux. If you chose to deviate from some
>>> parts of the tutorial, you're more or less on your own.
>>>
>>>
>>>>
>>>> On Tuesday, March 8, 2016 at 12:35:56 PM UTC+1, Jochen Eisinger wrote:
>>>>
>>>>> If you use make for your development, it should work. Just building
>>>>> x64.release should create the hello_world binary.
>>>>>
>>>>> The command line from the example is still linux specific (and
>>>>> predates the time we added hello_world to the "all" build target...)
>>>>>
>>>>> On Tue, Mar 8, 2016 at 12:14 PM Frank Lyder Bredland <
>>>>> knarfp...@gmail.com> wrote:
>>>>>
>>>>>> I'm not sure what you mean when you say "hello_world target"? or why
>>>>>> this shouldn't 

Re: [v8-dev] Building on OSX problems

[Jochen Eisinger]

Yeah, I guess we should invest in updating the tutorial for other OSs as
well. The set of libraries you have to link against is the same as on
Linux, however, the command line is different (and I don't know off the top
of my head how the correct command line for OSX would look like).

On Tue, Mar 8, 2016 at 2:50 PM Frank Lyder Bredland 
wrote:

> Seems like your correct about the tutorial being for Linux, I just assumed
> that it would be the same for OSX since they are both *nix systems, thats
> my fault.
> I however would wish that there also was a Windows and OSX version of the
> tutorial.
>
> Seems like there was a binary in ./out/x64.release/hello-world just as you
> said. So even if the tutorial was for Linux I guess it worked on OSX?
>
> I'd wished that this made me any wiser, but how am I supposed to link this
> against my own application?
> I mean, I guess I could just change the hello_world example and keep my
> whole application in that file, but I guess thats not the best way to
> develop C++ applications while embedding V8.
>
> What I would like to do is in some way build something that I could link
> against my application.
>
> How would I go about doing that?
> Normally for other libraries you could download the header files and some
> pre-build libraries for your platform.
> Since I can't find this option for V8 I'm guessing you have to build from
> source.
> Running "make x64.release" worked and I was able to run the hello_world
> example, so I guess building works.
>
> Now how would link against this on OSX? I'm at a bit of a loss, since the
> example is for Linux and there are no example for OSX.
>
> On Tuesday, March 8, 2016 at 2:37:06 PM UTC+1, Jochen Eisinger wrote:
>
>>
>>
>> On Tue, Mar 8, 2016 at 2:00 PM Frank Lyder Bredland 
>> wrote:
>>
>>> Okay, I'm afraid most of what your saying is gibberish to me.
>>> It's a bit hard trying to get V8 to work when literally the first
>>> example doesn't work.
>>>
>>
>>
>> The tutorial explicitly says that it's targeting Linux...
>>
>>
>>> Could you give me a step-to-step tutorial on how I'm supposed to build
>>> the hello_world example?
>>>
>>
>> make x64.release is enough to build hello world. it's in
>> out/x64.release/hello-world
>>
>>
>>>
>>> What I tried, based on the tutorial (
>>> https://github.com/v8/v8/wiki/Getting%20Started%20with%20Embedding) was
>>> the following:
>>>
>>> $ fetch v8 # do download v8
>>> $ git checkout -b 4.8 -t branch-heads/4.8 # to get to the correct branch
>>> $ make x64.release # to build the lib?
>>>
>>> And then I copy-pasted the hello_world.cpp file from that page and
>>> tried to build it using the command that was listed there.
>>> Which gives me a bunch of errors for missing .a files.
>>>
>>> So my question is this:
>>>
>>> Can you explain it to me like I'm five, how to I build and run this
>>> hello_world.cpp example on OSX using make and gyp or whatever?
>>> If the example is outdated then how am I supposed to do it?
>>>
>>
>> The example assumes you use Linux. If you chose to deviate from some
>> parts of the tutorial, you're more or less on your own.
>>
>>
>>>
>>> On Tuesday, March 8, 2016 at 12:35:56 PM UTC+1, Jochen Eisinger wrote:
>>>
>>>> If you use make for your development, it should work. Just building
>>>> x64.release should create the hello_world binary.
>>>>
>>>> The command line from the example is still linux specific (and predates
>>>> the time we added hello_world to the "all" build target...)
>>>>
>>>> On Tue, Mar 8, 2016 at 12:14 PM Frank Lyder Bredland <
>>>> knarfp...@gmail.com> wrote:
>>>>
>>>>> I'm not sure what you mean when you say "hello_world target"? or why
>>>>> this shouldn't work on osx?
>>>>> I'm not looking to create a xcode project, just to build it using
>>>>> clang on the terminal.
>>>>>
>>>>> Is there any reason that "make x64.release" should not work on Mac?
>>>>>
>>>>>
>>>>> On Tuesday, March 8, 2016 at 11:51:49 AM UTC+1, Jochen Eisinger wrote:
>>>>>
>>>>>> This example command line only works on 64bit Linux.
>>>>>>
>>>>>> On Mac, just build the hello_world target. I d

Re: [v8-dev] Building on OSX problems

[Jochen Eisinger]

On Tue, Mar 8, 2016 at 2:00 PM Frank Lyder Bredland 
wrote:

> Okay, I'm afraid most of what your saying is gibberish to me.
> It's a bit hard trying to get V8 to work when literally the first example
> doesn't work.
>


The tutorial explicitly says that it's targeting Linux...


> Could you give me a step-to-step tutorial on how I'm supposed to build the
> hello_world example?
>

make x64.release is enough to build hello world. it's in
out/x64.release/hello-world


>
> What I tried, based on the tutorial (
> https://github.com/v8/v8/wiki/Getting%20Started%20with%20Embedding) was
> the following:
>
> $ fetch v8 # do download v8
> $ git checkout -b 4.8 -t branch-heads/4.8 # to get to the correct branch
> $ make x64.release # to build the lib?
>
> And then I copy-pasted the hello_world.cpp file from that page and tried
> to build it using the command that was listed there.
> Which gives me a bunch of errors for missing .a files.
>
> So my question is this:
>
> Can you explain it to me like I'm five, how to I build and run this
> hello_world.cpp example on OSX using make and gyp or whatever?
> If the example is outdated then how am I supposed to do it?
>

The example assumes you use Linux. If you chose to deviate from some parts
of the tutorial, you're more or less on your own.


>
> On Tuesday, March 8, 2016 at 12:35:56 PM UTC+1, Jochen Eisinger wrote:
>
>> If you use make for your development, it should work. Just building
>> x64.release should create the hello_world binary.
>>
>> The command line from the example is still linux specific (and predates
>> the time we added hello_world to the "all" build target...)
>>
>> On Tue, Mar 8, 2016 at 12:14 PM Frank Lyder Bredland 
>> wrote:
>>
>>> I'm not sure what you mean when you say "hello_world target"? or why
>>> this shouldn't work on osx?
>>> I'm not looking to create a xcode project, just to build it using clang
>>> on the terminal.
>>>
>>> Is there any reason that "make x64.release" should not work on Mac?
>>>
>>>
>>> On Tuesday, March 8, 2016 at 11:51:49 AM UTC+1, Jochen Eisinger wrote:
>>>
>>>> This example command line only works on 64bit Linux.
>>>>
>>>> On Mac, just build the hello_world target. I don't know off the top of
>>>> my head what the corresponding command line would be for xcodebuild, sorry
>>>>
>>>> On Mon, Mar 7, 2016 at 5:59 PM Frank Lyder Bredland <
>>>> knarfp...@gmail.com> wrote:
>>>>
>>> I tried to follow this guid:
>>>>> https://github.com/v8/v8/wiki/Getting%20Started%20with%20Embedding
>>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fv8%2Fv8%2Fwiki%2FGetting%2520Started%2520with%2520Embedding&sa=D&sntz=1&usg=AFQjCNGAkmnkMHKNwDI4_Ax0b6qwnWLMuw>
>>>>>
>>>>> Everything seem to work until I get to step 3 where I get the
>>>>> following:
>>>>>
>>>>>  v8 git:(4.8) ✗ g++ -I. hello_world.cpp -o hello_world -Wl,--start-group 
>>>>> out/x64.release/obj.target/{tools/gyp/libv8_{base,libbase,external_snapshot,libplatform},third_party/icu/libicu{uc,i18n,data}}.a
>>>>>  -Wl,--end-group -lrt -ldl -pthread -std=c++0x
>>>>> clang: error: no such file or directory: 
>>>>> 'out/x64.release/obj.target/tools/gyp/libv8_base.a'
>>>>> clang: error: no such file or directory: 
>>>>> 'out/x64.release/obj.target/tools/gyp/libv8_libbase.a'
>>>>> clang: error: no such file or directory: 
>>>>> 'out/x64.release/obj.target/tools/gyp/libv8_external_snapshot.a'
>>>>> clang: error: no such file or directory: 
>>>>> 'out/x64.release/obj.target/tools/gyp/libv8_libplatform.a'
>>>>> clang: error: no such file or directory: 
>>>>> 'out/x64.release/obj.target/third_party/icu/libicuuc.a'
>>>>> clang: error: no such file or directory: 
>>>>> 'out/x64.release/obj.target/third_party/icu/libicui18n.a'
>>>>> clang: error: no such file or directory: 
>>>>> 'out/x64.release/obj.target/third_party/icu/libicudata.a'
>>>>>
>>>>>
>>>>> Any idea how to get it to work?
>>>>>
>>>>> --
>>>>> --
>>>>> v8-dev mailing list
>>>>>
>>>> v8-...@googlegroups.com
>>>>
>>>>
>

Re: [v8-dev] Building on OSX problems

[Jochen Eisinger]

If you use make for your development, it should work. Just building
x64.release should create the hello_world binary.

The command line from the example is still linux specific (and predates the
time we added hello_world to the "all" build target...)

On Tue, Mar 8, 2016 at 12:14 PM Frank Lyder Bredland 
wrote:

> I'm not sure what you mean when you say "hello_world target"? or why this
> shouldn't work on osx?
> I'm not looking to create a xcode project, just to build it using clang on
> the terminal.
>
> Is there any reason that "make x64.release" should not work on Mac?
>
>
> On Tuesday, March 8, 2016 at 11:51:49 AM UTC+1, Jochen Eisinger wrote:
>
>> This example command line only works on 64bit Linux.
>>
>> On Mac, just build the hello_world target. I don't know off the top of my
>> head what the corresponding command line would be for xcodebuild, sorry
>>
>> On Mon, Mar 7, 2016 at 5:59 PM Frank Lyder Bredland 
>> wrote:
>>
> I tried to follow this guid:
>>> https://github.com/v8/v8/wiki/Getting%20Started%20with%20Embedding
>>>
>>> Everything seem to work until I get to step 3 where I get the following:
>>>
>>>  v8 git:(4.8) ✗ g++ -I. hello_world.cpp -o hello_world -Wl,--start-group 
>>> out/x64.release/obj.target/{tools/gyp/libv8_{base,libbase,external_snapshot,libplatform},third_party/icu/libicu{uc,i18n,data}}.a
>>>  -Wl,--end-group -lrt -ldl -pthread -std=c++0x
>>> clang: error: no such file or directory: 
>>> 'out/x64.release/obj.target/tools/gyp/libv8_base.a'
>>> clang: error: no such file or directory: 
>>> 'out/x64.release/obj.target/tools/gyp/libv8_libbase.a'
>>> clang: error: no such file or directory: 
>>> 'out/x64.release/obj.target/tools/gyp/libv8_external_snapshot.a'
>>> clang: error: no such file or directory: 
>>> 'out/x64.release/obj.target/tools/gyp/libv8_libplatform.a'
>>> clang: error: no such file or directory: 
>>> 'out/x64.release/obj.target/third_party/icu/libicuuc.a'
>>> clang: error: no such file or directory: 
>>> 'out/x64.release/obj.target/third_party/icu/libicui18n.a'
>>> clang: error: no such file or directory: 
>>> 'out/x64.release/obj.target/third_party/icu/libicudata.a'
>>>
>>>
>>> Any idea how to get it to work?
>>>
>>> --
>>> --
>>> 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+un...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Building on OSX problems

[Jochen Eisinger]

This example command line only works on 64bit Linux.

On Mac, just build the hello_world target. I don't know off the top of my
head what the corresponding command line would be for xcodebuild, sorry

On Mon, Mar 7, 2016 at 5:59 PM Frank Lyder Bredland 
wrote:

> I tried to follow this guid:
> https://github.com/v8/v8/wiki/Getting%20Started%20with%20Embedding
>
> Everything seem to work until I get to step 3 where I get the following:
>
>  v8 git:(4.8) ✗ g++ -I. hello_world.cpp -o hello_world -Wl,--start-group 
> out/x64.release/obj.target/{tools/gyp/libv8_{base,libbase,external_snapshot,libplatform},third_party/icu/libicu{uc,i18n,data}}.a
>  -Wl,--end-group -lrt -ldl -pthread -std=c++0x
> clang: error: no such file or directory: 
> 'out/x64.release/obj.target/tools/gyp/libv8_base.a'
> clang: error: no such file or directory: 
> 'out/x64.release/obj.target/tools/gyp/libv8_libbase.a'
> clang: error: no such file or directory: 
> 'out/x64.release/obj.target/tools/gyp/libv8_external_snapshot.a'
> clang: error: no such file or directory: 
> 'out/x64.release/obj.target/tools/gyp/libv8_libplatform.a'
> clang: error: no such file or directory: 
> 'out/x64.release/obj.target/third_party/icu/libicuuc.a'
> clang: error: no such file or directory: 
> 'out/x64.release/obj.target/third_party/icu/libicui18n.a'
> clang: error: no such file or directory: 
> 'out/x64.release/obj.target/third_party/icu/libicudata.a'
>
>
> Any idea how to get it to work?
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] V8 Code of Conduct

[Jochen Eisinger]

Hi all,

A diverse, welcoming environment is important to the V8 community. To that
end, and as part of the larger Chromium team, we're explicitly adopting the
Chromium Code of Conduct for all our communication channels.

I've added this statement to the V8 repository:
https://chromium.googlesource.com/v8/v8/+/master/CODE_OF_CONDUCT.md referencing
the Chromium Code of Conduct here:
https://chromium.googlesource.com/chromium/src/+/master/CODE_OF_CONDUCT.md

best
-jochen

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Build lib distribution

[Jochen Eisinger]

I'd expect you'll need libicui18n.so libicuuc.so libv8.so,
snapshot_blob.bin, and natives_blob.bin

If you don't want to implement your own v8::Platform, you'll also need
libv8_libbase.a
libv8_libplatform.a

as headers. everything under include/ is needed.

hth
-jochen

On Thu, Feb 18, 2016 at 11:50 AM  wrote:

> Hi,
> I've successfully built shared libs for android_arm.release. Can anyone
> suggest me the files(.a, .so and headers) that I've to copy to other system
> to use/embed.
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] How does the V8 perform deoptimization?

[Jochen Eisinger]

There's a highlevel blog post here:
http://floitsch.blogspot.de/2012/03/optimizing-for-v8-inlining.html

For details, you'll have to read the source.

hth
-jochen

On Thu, Feb 18, 2016 at 11:54 AM  wrote:

> I think the question is clear :)
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] How to debug v8 natives

[Jochen Eisinger]

no, that's not supported.

On Wed, Feb 17, 2016 at 2:11 PM  wrote:

> There is no unique address of a js function. The code for the js function
>> can move around, it can be compiled multiple times, etc..
>>
> I know, but in particular point of time I can look for address of a js
> function and go to it. V8 doesn't support this for debug purpose in gdb?
>
>
> On Wednesday, February 17, 2016 at 6:35:24 PM UTC+6, Jochen Eisinger wrote:
>
>> There is no unique address of a js function. The code for the js function
>> can move around, it can be compiled multiple times, etc..
>>
>> On Wed, Feb 17, 2016 at 1:32 PM  wrote:
>>
>>> But, where I need stop gdb in v8 so that it gives me address for js
>>> function?
>>>
>>> On Wednesday, February 17, 2016 at 5:34:36 PM UTC+6, Yang Guo wrote:
>>>
>>>> I'd google for "gdb set break point at address" :)
>>>>
>>>> On Wed, Feb 17, 2016, 09:42   wrote:
>>>>
>>>>> Thank Jochen, but I don't clearly understand how to set breakpoint on
>>>>> JS function? I can set breakpoints only on c++ functions in gdb.
>>>>>
>>>>> On Wednesday, February 17, 2016 at 2:07:04 PM UTC+6, Jochen Eisinger
>>>>> wrote:
>>>>>
>>>>>> V8 will move code objects around during garbage collection. If you
>>>>>> want to debug code in code objects, you'll have an easier time if you
>>>>>> disable this by passing --nocompact_code_space.
>>>>>>
>>>>>> Otherwise, using the regular commands to set breakpoints in gdb
>>>>>> should work just fine.
>>>>>>
>>>>>> On Wed, Feb 17, 2016 at 8:55 AM  wrote:
>>>>>>
>>>>> Hi v8 community!
>>>>>>>
>>>>>>> I have a js function:
>>>>>>>
>>>>>>> function foo(o) {
>>>>>>>  return o.x;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> print(foo(37));
>>>>>>>
>>>>>>>
>>>>>>> I can see asm code for this function via "--print-code" flag,
>>>>>>> but I want to set a breakpoint at this function and see asm code in
>>>>>>> my gdb.
>>>>>>>
>>>>>>> For example:
>>>>>>>
>>>>>>> If I see this code in logs:
>>>>>>> 0x1ec9f1e3eeb824  488bd0 REX.W movq rdx,rax
>>>>>>> 0x1ec9f1e3eebb27  48b959bb34fb3714 REX.W movq rcx,
>>>>>>> 0x1437fb34bb59;; debug: position 27
>>>>>>>  ;;
>>>>>>> object: 0x1437fb34bb59 
>>>>>>> 0x1ec9f1e3eec537  48b80100 REX.W movq rax,
>>>>>>> 0x1
>>>>>>> 0x1ec9f1e3eecf47  e8cc92fdff call 0x1ec9f1e181a0 ;; code
>>>>>>> : contextual, LOAD_IC, GENERIC
>>>>>>>   ]
>>>>>>>   [ Return sequence
>>>>>>> 0x1ec9f1e3eed452  48bb91d03dfb3714 REX.W movq rbx,
>>>>>>> 0x1437fb3dd091;; object: 0x1437fb3dd091 Cell for 6144
>>>>>>>
>>>>>>> In runtime I want to jump into 0x1ec9f1e181a0 and see what is happening
>>>>>>> there.
>>>>>>>
>>>>>>> How can I do this?
>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> 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+un...@googlegroups.com.
>>>>>>
>>>>>>
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>> --
>>>>> --
>>>>> 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+un...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>> --
>>> 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+un...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] How to debug v8 natives

[Jochen Eisinger]

There is no unique address of a js function. The code for the js function
can move around, it can be compiled multiple times, etc..

On Wed, Feb 17, 2016 at 1:32 PM  wrote:

> But, where I need stop gdb in v8 so that it gives me address for js
> function?
>
> On Wednesday, February 17, 2016 at 5:34:36 PM UTC+6, Yang Guo wrote:
>
>> I'd google for "gdb set break point at address" :)
>>
>> On Wed, Feb 17, 2016, 09:42   wrote:
>>
>>> Thank Jochen, but I don't clearly understand how to set breakpoint on JS
>>> function? I can set breakpoints only on c++ functions in gdb.
>>>
>>> On Wednesday, February 17, 2016 at 2:07:04 PM UTC+6, Jochen Eisinger
>>> wrote:
>>>
>>>> V8 will move code objects around during garbage collection. If you want
>>>> to debug code in code objects, you'll have an easier time if you disable
>>>> this by passing --nocompact_code_space.
>>>>
>>>> Otherwise, using the regular commands to set breakpoints in gdb should
>>>> work just fine.
>>>>
>>>> On Wed, Feb 17, 2016 at 8:55 AM  wrote:
>>>>
>>> Hi v8 community!
>>>>>
>>>>> I have a js function:
>>>>>
>>>>> function foo(o) {
>>>>>  return o.x;
>>>>> }
>>>>>
>>>>>
>>>>> print(foo(37));
>>>>>
>>>>>
>>>>> I can see asm code for this function via "--print-code" flag,
>>>>> but I want to set a breakpoint at this function and see asm code in my
>>>>> gdb.
>>>>>
>>>>> For example:
>>>>>
>>>>> If I see this code in logs:
>>>>> 0x1ec9f1e3eeb824  488bd0 REX.W movq rdx,rax
>>>>> 0x1ec9f1e3eebb27  48b959bb34fb3714 REX.W movq rcx,
>>>>> 0x1437fb34bb59;; debug: position 27
>>>>>  ;; object
>>>>> : 0x1437fb34bb59 
>>>>> 0x1ec9f1e3eec537  48b80100 REX.W movq rax,0x1
>>>>> 0x1ec9f1e3eecf47  e8cc92fdff call 0x1ec9f1e181a0 ;; code:
>>>>> contextual, LOAD_IC, GENERIC
>>>>>   ]
>>>>>   [ Return sequence
>>>>> 0x1ec9f1e3eed452  48bb91d03dfb3714 REX.W movq rbx,
>>>>> 0x1437fb3dd091;; object: 0x1437fb3dd091 Cell for 6144
>>>>>
>>>>> In runtime I want to jump into 0x1ec9f1e181a0 and see what is happening
>>>>> there.
>>>>>
>>>>> How can I do this?
>>>>>
>>>>> --
>>>>> --
>>>>> 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+un...@googlegroups.com.
>>>>
>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>>> --
>>> 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+un...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] How to debug v8 natives

[Jochen Eisinger]

V8 will move code objects around during garbage collection. If you want to
debug code in code objects, you'll have an easier time if you disable this
by passing --nocompact_code_space.

Otherwise, using the regular commands to set breakpoints in gdb should work
just fine.

On Wed, Feb 17, 2016 at 8:55 AM  wrote:

> Hi v8 community!
>
> I have a js function:
>
> function foo(o) {
>  return o.x;
> }
>
>
> print(foo(37));
>
>
> I can see asm code for this function via "--print-code" flag,
> but I want to set a breakpoint at this function and see asm code in my
> gdb.
>
> For example:
>
> If I see this code in logs:
> 0x1ec9f1e3eeb824  488bd0 REX.W movq rdx,rax
> 0x1ec9f1e3eebb27  48b959bb34fb3714 REX.W movq rcx,0x1437fb34bb59
>;; debug: position 27
>  ;; object:
> 0x1437fb34bb59 
> 0x1ec9f1e3eec537  48b80100 REX.W movq rax,0x1
> 0x1ec9f1e3eecf47  e8cc92fdff call 0x1ec9f1e181a0 ;; code:
> contextual, LOAD_IC, GENERIC
>   ]
>   [ Return sequence
> 0x1ec9f1e3eed452  48bb91d03dfb3714 REX.W movq rbx,0x1437fb3dd091
>;; object: 0x1437fb3dd091 Cell for 6144
>
> In runtime I want to jump into 0x1ec9f1e181a0 and see what is happening
> there.
>
> How can I do this?
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Re: How to access data passed to SetAccessCheckCallback from AccessCheckCallback?

[Jochen Eisinger]

thanks for the report, I submitted a fix

On Wed, Feb 3, 2016 at 11:01 PM  wrote:

> Here is a gist to demonstrate problem -
> https://gist.github.com/pinepain/0d9c04228d92c88bf7f7
>
>
> On Wednesday, February 3, 2016 at 11:29:38 PM UTC+2, zaq17...@gmail.com
> wrote:
>>
>> Thanks for adding data parameter.
>>
>> I tried v8 from 4.10.148 tag (which has
>> https://github.com/v8/v8/commit/a75b2c8f69634685288b419c8b4daf2d661b4bf4
>> commit), but data from AccessCheckCallback is reported as IsEmpty()
>> regardless what I set it to =(
>>
>> On Tuesday, February 2, 2016 at 3:58:43 PM UTC+2, Jochen Eisinger wrote:
>>>
>>> it's only used for failed access checks.
>>>
>>> anyways, I'll add the data parameter
>>>
>>>
>>> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Re: How to access data passed to SetAccessCheckCallback from AccessCheckCallback?

[Jochen Eisinger]

it's only used for failed access checks.

anyways, I'll add the data parameter

On Tue, Feb 2, 2016 at 2:20 PM  wrote:

> While interceptors may be a solution, I already have code that have
> cross-context access and uses Named/Indexed access checker (at some part it
> mimic browser cross-origin policy), so having data property to migrate from
> deprecated checkers to newer one is mandatory for me. And if no data passed
> to callback, what is the purpose of that data parameter in
> SetAccessCheckCallback()?
>
>
> On Tuesday, February 2, 2016 at 3:07:02 PM UTC+2, Jochen Eisinger wrote:
>
>> Blink was merged into chromium a while ago, so there is no separate repo.
>>
>> As Toon points out, access checks will only trigger on cross-context
>> accesses, and probably not work for the code snippet you posted.
>>
>> Maybe your use case can be modelled using regular interceptors?
>>
>> best
>> -jochen
>>
>> On Tue, Feb 2, 2016 at 11:41 AM Toon Verwaest 
>> wrote:
>>
> Access checks only have meaning in a setting with multiple contexts from
>>> multiple origins. Unlike the other callback mechanisms, it's unlikely
>>> you'll want to use this mechanism in a non-browser setting.
>>>
>>> Regards,
>>> Toon
>>>
>>> On Tue, Feb 2, 2016, 11:28   wrote:
>>>
>>>> Maybe I cloned wrong blink repo (
>>>> https://chromium.googlesource.com/chromium/blink)? Just noted that
>>>> latest changes there is 4 month old.
>>>>
>>>> I writ php binding to v8 API (don't be confused with v8js), so my
>>>> typical use case for data in callbacks (or {Function,Property}CallbackInfo
>>>> obj) is to pass actual php function (specified in PHP runtime in userland)
>>>> that will be executed.
>>>>
>>>> meta-code is (use AccessCheckCallback to demonstrate the idea):
>>>>
>>>> v8::Local data;
>>>> v8::AccessCheckCallback callback = nullptr;
>>>>
>>>> if (php_callback) {
>>>> data = v8::External::New(isolate, to_callbacks_bucket(0,
>>>> php_callback));
>>>> callback = php_v8_callback_access_check;
>>>> }
>>>>
>>>> v8::Local template =
>>>> php_v8_object_template_get_local(isolate, php_v8_object_template);
>>>>
>>>> local_template->SetAccessCheckCallback(callback, data);
>>>>
>>>> //
>>>> bool php_v8_callback_access_check(v8::Local
>>>> accessing_context, v8::Local accessed_object/*,
>>>> v8::Local data*/) {
>>>> bool security_retval = false;
>>>> zval retval;
>>>> zval args; // = [to_php_internal_repr(accessing_context),
>>>> to_php_internal_repr(accessed_object)];
>>>>
>>>> php_v8_callback_call_from_bucket_with_zargs(0/*, data*/, &args, &
>>>> retval);
>>>>
>>>> if (Z_TYPE(retval) == IS_TRUE) {
>>>> security_retval = true;
>>>> }
>>>>
>>>> return security_retval;
>>>> }
>>>>
>>>> void php_v8_callback_call_from_bucket_with_zargs(size_t index, v8::
>>>> Local data, zval *args, zval *retval) {
>>>> php_v8_callbacks_bucket_t *bucket;
>>>>
>>>> if (data.IsEmpty() || !data->IsExternal()) {
>>>> PHP_V8_THROW_EXCEPTION("Callback has no stored callback
>>>> function");
>>>> return;
>>>> }
>>>>
>>>> bucket = static_cast(v8::Local>>> External>::Cast(data)->Value());
>>>> assert(bucket->size > index);
>>>> //...
>>>> }
>>>>
>>>> I use similar approach for all callbacks in v8 like (incl. now
>>>> deprecated NamedSecurityCallback and IndexedSecurityCallback) or Data()
>>>> accessor on PropertyCallbackInfo, FunctionCallback and others like
>>>> these.
>>>>
>>>>
>>>> On Tuesday, February 2, 2016 at 11:56:51 AM UTC+2, Jochen Eisinger
>>>> wrote:
>>>>
>>>>> I'll do something similar.
>>>>>
>>>>> Note that blink already uses the new API, but it doesn't need data in
>>>>> the callbacks - just in the failed access check callbacks.
>>>>>
>>>>> May I ask what you're using the callbacks for? they're pretty much
>>>>> cus

Re: [v8-dev] Re: How to access data passed to SetAccessCheckCallback from AccessCheckCallback?

[Jochen Eisinger]

Blink was merged into chromium a while ago, so there is no separate repo.

As Toon points out, access checks will only trigger on cross-context
accesses, and probably not work for the code snippet you posted.

Maybe your use case can be modelled using regular interceptors?

best
-jochen

On Tue, Feb 2, 2016 at 11:41 AM Toon Verwaest  wrote:

> Access checks only have meaning in a setting with multiple contexts from
> multiple origins. Unlike the other callback mechanisms, it's unlikely
> you'll want to use this mechanism in a non-browser setting.
>
> Regards,
> Toon
>
> On Tue, Feb 2, 2016, 11:28   wrote:
>
>> Maybe I cloned wrong blink repo (
>> https://chromium.googlesource.com/chromium/blink)? Just noted that
>> latest changes there is 4 month old.
>>
>> I writ php binding to v8 API (don't be confused with v8js), so my typical
>> use case for data in callbacks (or {Function,Property}CallbackInfo obj) is
>> to pass actual php function (specified in PHP runtime in userland) that
>> will be executed.
>>
>> meta-code is (use AccessCheckCallback to demonstrate the idea):
>>
>> v8::Local data;
>> v8::AccessCheckCallback callback = nullptr;
>>
>> if (php_callback) {
>> data = v8::External::New(isolate, to_callbacks_bucket(0, php_callback
>> ));
>> callback = php_v8_callback_access_check;
>> }
>>
>> v8::Local template = php_v8_object_template_get_local
>> (isolate, php_v8_object_template);
>>
>> local_template->SetAccessCheckCallback(callback, data);
>>
>> //
>> bool php_v8_callback_access_check(v8::Local
>> accessing_context, v8::Local accessed_object/*,
>> v8::Local data*/) {
>> bool security_retval = false;
>> zval retval;
>> zval args; // = [to_php_internal_repr(accessing_context),
>> to_php_internal_repr(accessed_object)];
>>
>> php_v8_callback_call_from_bucket_with_zargs(0/*, data*/, &args, &
>> retval);
>>
>> if (Z_TYPE(retval) == IS_TRUE) {
>> security_retval = true;
>> }
>>
>> return security_retval;
>> }
>>
>> void php_v8_callback_call_from_bucket_with_zargs(size_t index, v8::Local<
>> v8::Value> data, zval *args, zval *retval) {
>> php_v8_callbacks_bucket_t *bucket;
>>
>> if (data.IsEmpty() || !data->IsExternal()) {
>> PHP_V8_THROW_EXCEPTION("Callback has no stored callback function"
>> );
>> return;
>> }
>>
>> bucket = static_cast(v8::Local> External>::Cast(data)->Value());
>> assert(bucket->size > index);
>> //...
>> }
>>
>> I use similar approach for all callbacks in v8 like (incl. now deprecated
>> NamedSecurityCallback and IndexedSecurityCallback) or Data() accessor on 
>> PropertyCallbackInfo,
>> FunctionCallback and others like these.
>>
>>
>> On Tuesday, February 2, 2016 at 11:56:51 AM UTC+2, Jochen Eisinger wrote:
>>
>>> I'll do something similar.
>>>
>>> Note that blink already uses the new API, but it doesn't need data in
>>> the callbacks - just in the failed access check callbacks.
>>>
>>> May I ask what you're using the callbacks for? they're pretty much
>>> custom made for the use case in blink, so chances are they don't do what
>>> you think they do :-/
>>>
>>> On Tue, Feb 2, 2016 at 9:58 AM  wrote:
>>>
>>>> Thanks for quick reply.
>>>>
>>>> Can you then apply patch above, please?
>>>>
>>>> Missed data looks definitely like a minor mistake during moving to new
>>>> SetAccessCheckCallback
>>>> (here you fix some of data
>>>> https://github.com/v8/v8/commit/e2675937d5b6d2e555edeaabcda7ce70551ea236
>>>> ).
>>>> I checked blink code and if one decides to move to
>>>> SetAccessCheckCallback there, passing data to callback is a must.
>>>>
>>>>
>>>> On Tuesday, February 2, 2016 at 10:36:58 AM UTC+2, Jochen Eisinger
>>>> wrote:
>>>>>
>>>>> afaik there was no reason to drop data from the callback other that we
>>>>> didn't know of anybody using it.
>>>>>
>>>>
>>>>
>>>>
>>>>> I guess it's fine to add it back.
>>>>>
>>>>> On Mon, Feb 1, 2016 at 10:44 PM  wrote:
>>>>>
>>>> I guess something like this may allow data passing to callback:
>>>>>&

Re: [v8-dev] Re: How to access data passed to SetAccessCheckCallback from AccessCheckCallback?

[Jochen Eisinger]

I'll do something similar.

Note that blink already uses the new API, but it doesn't need data in the
callbacks - just in the failed access check callbacks.

May I ask what you're using the callbacks for? they're pretty much custom
made for the use case in blink, so chances are they don't do what you think
they do :-/

On Tue, Feb 2, 2016 at 9:58 AM  wrote:

> Thanks for quick reply.
>
> Can you then apply patch above, please?
>
> Missed data looks definitely like a minor mistake during moving to new
> SetAccessCheckCallback
> (here you fix some of data
> https://github.com/v8/v8/commit/e2675937d5b6d2e555edeaabcda7ce70551ea236).
> I checked blink code and if one decides to move to SetAccessCheckCallback
> there, passing data to callback is a must.
>
>
> On Tuesday, February 2, 2016 at 10:36:58 AM UTC+2, Jochen Eisinger wrote:
>>
>> afaik there was no reason to drop data from the callback other that we
>> didn't know of anybody using it.
>>
>
>
>
>> I guess it's fine to add it back.
>>
>> On Mon, Feb 1, 2016 at 10:44 PM  wrote:
>>
> I guess something like this may allow data passing to callback:
>>>
>>> diff --git a/include/v8.h b/include/v8.h
>>> index 171623a..afeb043 100644
>>> --- a/include/v8.h
>>> +++ b/include/v8.h
>>> @@ -4322,7 +4322,8 @@ enum AccessType {
>>>   * object.
>>>   */
>>>
>>>  typedef bool (*AccessCheckCallback)(Local accessing_context,
>>> -Local accessed_object);
>>> +Local accessed_object,
>>> +Local data = Local());
>>>
>>>
>>>  /**
>>> diff --git a/src/isolate.cc b/src/isolate.cc
>>> index 40d4c9f..2d15420 100644
>>> --- a/src/isolate.cc
>>> +++ b/src/isolate.cc
>>> @@ -843,7 +843,8 @@ bool Isolate::MayAccess(Handle
>>> accessing_context,
>>>  VMState state(this);
>>>  if (callback) {
>>>return callback(v8::Utils::ToLocal(accessing_context),
>>> -  v8::Utils::ToLocal(receiver));
>>> +  v8::Utils::ToLocal(receiver),
>>> +  v8::Utils::ToLocal(data));
>>>  }
>>>  Handle key = factory()->undefined_value();
>>>  return named_callback(v8::Utils::ToLocal(receiver), v8::Utils::
>>> ToLocal(key),
>>>
>>>
>>> didn't tried it yet, but is idea correct or there was some other reason
>>> to drop data?
>>>
>>> --
>>> --
>>> 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+un...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Re: How to access data passed to SetAccessCheckCallback from AccessCheckCallback?

[Jochen Eisinger]

afaik there was no reason to drop data from the callback other that we
didn't know of anybody using it.

I guess it's fine to add it back.

On Mon, Feb 1, 2016 at 10:44 PM  wrote:

> I guess something like this may allow data passing to callback:
>
> diff --git a/include/v8.h b/include/v8.h
> index 171623a..afeb043 100644
> --- a/include/v8.h
> +++ b/include/v8.h
> @@ -4322,7 +4322,8 @@ enum AccessType {
>   * object.
>   */
>
>  typedef bool (*AccessCheckCallback)(Local accessing_context,
> -Local accessed_object);
> +Local accessed_object,
> +Local data = Local());
>
>
>  /**
> diff --git a/src/isolate.cc b/src/isolate.cc
> index 40d4c9f..2d15420 100644
> --- a/src/isolate.cc
> +++ b/src/isolate.cc
> @@ -843,7 +843,8 @@ bool Isolate::MayAccess(Handle
> accessing_context,
>  VMState state(this);
>  if (callback) {
>return callback(v8::Utils::ToLocal(accessing_context),
> -  v8::Utils::ToLocal(receiver));
> +  v8::Utils::ToLocal(receiver),
> +  v8::Utils::ToLocal(data));
>  }
>  Handle key = factory()->undefined_value();
>  return named_callback(v8::Utils::ToLocal(receiver), v8::Utils::
> ToLocal(key),
>
>
> didn't tried it yet, but is idea correct or there was some other reason to
> drop data?
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Re: Local::Local(S* that) constructor screws up implicit conversions for overloaded functions

[Jochen Eisinger]

Hey,

thanks for looking into this. I guess the reason this hasn't come up before
is that our styleguide explicitly disallows function overloading (
https://google.github.io/styleguide/cppguide.html#Function_Overloading)

However, I think it's reasonable to support other styles here as well. Have
you considered contributing a patch?

best
-jochen

On Thu, Jan 28, 2016 at 2:28 AM  wrote:

> or perhaps the template on the constructor isn't even necessary?
>
> http://ideone.com/MXwvp9
>
> shows the same behavior.
>
> V8_INLINE Local(T* that)
>  : val_(that) {}
> V8_INLINE static Local New(Isolate* isolate, T* that);
> T* val_;
>
> On Wednesday, January 27, 2016 at 5:16:54 PM UTC-8, xax...@gmail.com
> wrote:
>>
>> I think I simply had the parameters to is_convertible backwards in my
>> first post:
>>
>> template 
>> ::value>>
>> V8_INLINE Local(S* that)
>>  : val_(that) {}
>> V8_INLINE static Local New(Isolate* isolate, T* that);
>> T* val_;
>>
>>
>> This link http://ideone.com/RVL4rD shows overloaded functions being
>> selected appropriately as well as pointer assignment working between
>> compatible types.
>>
>> On Wednesday, January 27, 2016 at 5:03:49 PM UTC-8, xax...@gmail.com
>> wrote:
>>>
>>> is_convertible doesn't seem to be the right test.   I'm trying to figure
>>> out if I can find a better one.
>>>
>>> On Wednesday, January 27, 2016 at 4:48:56 PM UTC-8, xax...@gmail.com
>>> wrote:
>>>>
>>>> I have an overloaded function that can take either a std::string or a
>>>> Local, however, when I pass in a const char *, expecting to have the
>>>> std::string version selected, I instead get an ambiguity error.  I added
>>>> another version that takes a Local

Re: [v8-dev] A bug in android-sync tool

[Jochen Eisinger]

you should run

depot-tools-auth login https://codereview.chromium.org

on the command line. If this opens in a different browser session than the
one where you're logged into codereview.chromium.org, just copy the URL
over to the codereview.chromium.org window and approve access.

Then you should be able to use git cl upload

On Fri, Jan 22, 2016 at 8:46 AM Bangfu Tao  wrote:

> Hi Jochen,
>
> I can also login with Samsung address on codereview.chromium.org.
> Just wondering, do I need to do "git cl config"? If yes, please show me
> how to.
>
> Thanks
> Bangfu
>
>
>
> On Thu, Jan 21, 2016 at 11:30 AM, Jochen Eisinger 
> wrote:
>
>> can you login with your samsung address on codereview.chromium.org? If
>> not, did you ever create a google account for that address?
>>
>> best
>> -jochen
>>
>> On Thu, Jan 21, 2016 at 12:08 PM 'Daniel Vogelheim' via v8-dev <
>> v8-dev@googlegroups.com> wrote:
>>
>>> On Thu, Jan 21, 2016 at 10:36 AM, Yang Guo  wrote:
>>>
>>>> This looks like a necessary change, Thanks! Daniel, Ulan, does this
>>>> look right to you guys?
>>>>
>>>
>>> The change looks good, assuming that sync_file does nothing if the
>>> source file doesn't exist.
>>>
>>> The default build now uses the two *_blob.bin files, but this can be
>>> disabled. So there can still be builds without either *_blob.bin, and in
>>> that case the sync script should still work.
>>>
>>> --
>>> --
>>> v8-dev mailing list
>>> v8-dev@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.
>>>
>> --
>> --
>> v8-dev mailing list
>> v8-dev@googlegroups.com
>> http://groups.google.com/group/v8-dev
>> ---
>>
> You received this message because you are subscribed to a topic in the
>> Google Groups "v8-dev" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/v8-dev/uXhjHPoT7rc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> v8-dev+unsubscr...@googlegroups.com.
>>
>
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] A bug in android-sync tool

[Jochen Eisinger]

can you login with your samsung address on codereview.chromium.org? If not,
did you ever create a google account for that address?

best
-jochen

On Thu, Jan 21, 2016 at 12:08 PM 'Daniel Vogelheim' via v8-dev <
v8-dev@googlegroups.com> wrote:

> On Thu, Jan 21, 2016 at 10:36 AM, Yang Guo  wrote:
>
>> This looks like a necessary change, Thanks! Daniel, Ulan, does this look
>> right to you guys?
>>
>
> The change looks good, assuming that sync_file does nothing if the source
> file doesn't exist.
>
> The default build now uses the two *_blob.bin files, but this can be
> disabled. So there can still be builds without either *_blob.bin, and in
> that case the sync script should still work.
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] Add support for compiling V8 standalone using gn (issue 1067293002 by joc...@chromium.org)

[jochen]

Reviewers:
CL: https://codereview.chromium.org/1067293002/

Description:
Add support for compiling V8 standalone using gn

BUG=chromium:474921
LOG=y

Base URL: https://chromium.googlesource.com/v8/v8.git@master

Affected files (+101, -0 lines):
  M .gitignore
  A .gn
  M DEPS
  A build/module_args/v8.gni


--
--
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: Implement tracing interface for v8 (issue 988893003 by fmea...@chromium.org)

[jochen]

https://codereview.chromium.org/988893003/diff/420001/include/v8-platform.h
File include/v8-platform.h (right):

https://codereview.chromium.org/988893003/diff/420001/include/v8-platform.h#newcode120
include/v8-platform.h:120: virtual const uint8_t*
GetCategoryGroupEnabled(const char* name) = 0;
we might also want to provide default implementations here to make it
easier for embedders to roll forward

https://codereview.chromium.org/988893003/

--
--
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: Implement tracing interface for v8 (issue 988893003 by fmea...@chromium.org)

[jochen]

On 2015/12/01 at 17:04:41, jochen wrote:

https://codereview.chromium.org/988893003/diff/420001/DEPS
File DEPS (right):



https://codereview.chromium.org/988893003/diff/420001/DEPS#newcode16
DEPS:16: "v8/src/tracing/common":
I think this line should be v8/base/trace_event/common


I'm taking care of this..

https://codereview.chromium.org/988893003/

--
--
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Re: An update on bit_cast

[Jochen Eisinger]

thanks for the heads-up.

Did you keep the bit_casts in fletch for non-pointer types?

On Thu, Dec 3, 2015 at 2:34 PM 'Erik Corry' via v8-dev <
v8-dev@googlegroups.com> wrote:

> Slava points out that I am writing about use of bit_cast for pointer types
> (eg casting an Object** to a Class**), but ignoring the other use of
> bit_cast (eg casting a float to a uint32_t).  It's only the pointer types
> that are problematic, I think.
>
> On 3 December 2015 at 13:37, Erik Corry  wrote:
>
>> Some investigation by ager and some asking around has resulted in the
>> conclusion that bit_cast only serves to prevent warnings.  It doesn't
>> actually fix the program's use of undefined behaviour.  Mads was able to
>> get gcc to generate broken code for a function with strict aliasing issues
>> both with and without bit_cast.
>>
>> We have ripped bit_cast out of Fletch, replacing it with reinterpret_cast
>> everywhere.
>>
>> We have also added the -fno-strict-aliasing, since there's no sensible
>> way to fix a GC and a runtime for a dynamic language so it doesn't alias
>> pointers.  (The only way I can think of involves getting rid of the C++
>> "Object" class and treating the heap as a char array, which would be
>> horrible beyond belief).  This flag is available on both Clang and gcc, and
>> is the default behaviour for MSVC.  If you add the same flag to V8 you may
>> see a small performance regression on Linux, but not on Mac and Windows
>> where I think it already is the default.
>>
>> --
>> Erik Corry
>>
>> Google Denmark ApS
>> Frederiksborggade 20B, 1 sal
>> 1360 København K
>> Denmark
>> CVR nr. 28 86 69 84
>>
>
>
>
> --
> Erik Corry
>
> Google Denmark ApS
> Frederiksborggade 20B, 1 sal
> 1360 København K
> Denmark
> CVR nr. 28 86 69 84
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: Implement tracing interface for v8 (issue 988893003 by fmea...@chromium.org)

[jochen]

https://codereview.chromium.org/988893003/diff/420001/DEPS
File DEPS (right):

https://codereview.chromium.org/988893003/diff/420001/DEPS#newcode16
DEPS:16: "v8/src/tracing/common":
I think this line should be v8/base/trace_event/common

https://codereview.chromium.org/988893003/

--
--
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: Implement tracing interface for v8 (issue 988893003 by fmea...@chromium.org)

[jochen]

i guess v8 needs to depend on a target defined in the new DEPS entry to  
build

with chromium


https://codereview.chromium.org/988893003/diff/41/BUILD.gn
File BUILD.gn (right):

https://codereview.chromium.org/988893003/diff/41/BUILD.gn#newcode1271
BUILD.gn:1271: "src/tracing/trace-event.h",
the cc file needs to be added here as well

https://codereview.chromium.org/988893003/

--
--
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: [turbofan] Add backend support for float32 operations. (issue 1044793002 by bmeu...@chromium.org)

[jochen]

https://codereview.chromium.org/1044793002/diff/20001/test/cctest/test-disasm-arm.cc
File test/cctest/test-disasm-arm.cc (right):

https://codereview.chromium.org/1044793002/diff/20001/test/cctest/test-disasm-arm.cc#newcode98
test/cctest/test-disasm-arm.cc:98: // clang-format off
please don't do that. clang-format off is supposed to be used for a
scope of things you want to format differently, not as a blanket thing
for an entire file

https://codereview.chromium.org/1044793002/

--
--
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: Finish 'MIPS: [turbofan] Add backend support for float32 operations.' (issue 1047213002 by balazs.kilv...@imgtec.com)

[jochen]

https://codereview.chromium.org/1047213002/diff/20001/test/cctest/test-assembler-mips.cc
File test/cctest/test-assembler-mips.cc (right):

https://codereview.chromium.org/1047213002/diff/20001/test/cctest/test-assembler-mips.cc#newcode49
test/cctest/test-assembler-mips.cc:49: // clang-format off
please don't do this. clang-format off is meant to be used a small
scope, not a blanket thing for the entire file.

https://codereview.chromium.org/1047213002/

--
--
v8-dev mailing list
v8-dev@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.

[v8-dev] making fast math functions per-isolate?

[Jochen Eisinger]

Hey,

currently the fast_exp and fast_sqrt functions are globally defined. This
has some issues, however:

We need an isolate to instantiate them. Then, when they're assembled, we
need to flush the icache (which we actually don't do on intel with a
comment saying that we never execute the same code from multiple
threads...), and on archs that have a simulator, we then need the isolate
to get to the simulator to actually run the code.

Right now, we use whatever isolate happens to be in TLS at the time the
methods are invoked.

I'd propose to make those two functions per isolate instead, so instead of
getting to the methods via global static variables, all callsites have to
get to them via the isolate, and we'd automatically have the correct
isolate to use (also the comment about the icache would be true again...)

comments?
-jochen

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: Use msvs toolchain from depot_tools. (issue 1237803003 by machenb...@chromium.org)

[jochen]

no idea

lgtm anyways

https://codereview.chromium.org/1237803003/

--
--
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Re: Isolate entry stacking bug?

[Jochen Eisinger]

Hey,

thanks for the detailed analysis. Currently, we conceptually support two
modes: either you use one isolate per thread, or you use one isolate and
share it with many different threads.

It's of course possible to use multiple isolates the way you described it,
and if you want to contribute code to make this possible, that's highly
appreciated.

As you point out, we work towards having the embedder always provide the
isolate to use, so we would no longer have to store any data in tls, but
that's still far out in the future.

best
-jochen

On Wed, Oct 21, 2015 at 7:27 PM Alex Kodat  wrote:

> Since my last e-mail generated so much excitement I guess I'll toss out a
> proposal for how I would fix this and, while the heart is on the table,
> deal with the thread cleanup issue that led me down this path.
>
> First, I'll note that I suspect that the lack of interest in the bug that
> I described (and might well be wrong about) is that there is a hope that
> the entry stack is going away soon anyway. Since its only purpose seems to
> be to set the result of Isolate::GetCurrent which seems to be on the road
> to deprecation maybe no one cares? However, if the entry stack will be
> around for at least another year or two, I think it should be fixed. If
> not, then my proposal below might still make sense but is probably less
> compelling.
>
> Whether or not Isolate::GetCurrent is going away, I'll opine that the
> Isolate::Enter and Isolate::Exit should be deprecated and people should
> just use Isolate::Scope (which ultimately will be deprecated or at least
> no-oped, too?) as the DIY Enter/Exit matching seems pretty sketchy and not
> particularly useful.
>
> Leaving that aside, I would propose a PerThreadData anchor block that each
> thread has at most one of and is accessed via per_isolate_thread_data_key_
> (perhaps renamed to per_thread_data_key_). This block could contain an
> anchor for the PerIsolateThreadData for the owning thread and, if the task
> entry stack is not going way, the EntryStackItem stack and even the current
> isolate; again, likely to go away but, for now, obviating the need for the
> isolate_key_ thread key.
>
> In any case, a PerThreadData anchor block for the PerIsolateThreadData
> would eliminate the need for a mutex to find, add, or remove
> PerIsolateThreadData and would make safe/automatic cleanup of this data
> much easier. In my original post on thread data cleanup Jakob had stongly
> opined that I just just propose a separate call
> DiscardThreadSpecificMetadata() to allow embedders to clean up after
> themselves in threads because he felt doing it automatically was too risky
> which I thought was fair enough but, if folks feel the entry stack issues
> should be fixed too, then the automatic PerIsolateThreadData cleanup seems
> a pretty minor addition to such a project. It seems it would be preferable
> to do things automatically than have yet another embedder method.
>
> As far as testing what I'm proposing goes, I think the hacked hello-world
> demonstration of the entry stack bug could be converted fairly easily into
> a relatively general purpose thread test harness (but maybe there already
> is one?). Its use of a semaphore array could be combined with thread
> specific arrays that map out each thread's plan of attack. The semaphore's
> ensure deterministic ordering of each thread's isolate
> entry/exit/locking/unlocking. But probably there's already something out
> there for testing lazy/eager archiving/restoring so I'd add appropriate
> tests using that, if possible.
>
> On Tuesday, October 20, 2015 at 9:22:42 AM UTC-7, Alex Kodat wrote:
>>
>> Jakob had suggested that I post a proposal to v8-users related to a thread
>> cleanup issue
>> <https://groups.google.com/forum/#!topic/v8-users/iZ1gz1KThgs> which I
>> plan on doing, but his comments about threads going in and out of isolates
>> got me curious about thread entry/exit mechanics which led me to puzzlement
>> about the use of Isolate::entry_stack_. Specifically, it seemed to make no
>> sense at all to me for this to be in Isolate. The entry stack is a per
>> thread thing and no one other than the thread that owns a stack entry needs
>> to look at it so why is it in Isolate? It wouldn't matter if this were
>> harmless but it seems that Isolate::Enter happily sets a pointer to another
>> thread's EntryStackItem if one happened to be in entry_stack_ for the new
>> Isolate and Isolate:Exit then happily sets it back to whatever it was when
>> it entered the isolate,  regardless of what that thread or other threads
>> that might have entered this Isolate are doing. Having one thread messing
>> with anoth

Re: [v8-dev] Re: Stack limits and AST visitors

[Jochen Eisinger]

The 'main thread' for a isolate is supposed to be interruptable, e.g., via
Isolate::RequestInterrupt or Isolate::TerminateExecution.

I can't answer your question about how the parser / ast visitors is
supposed to behave here :-/

On Mon, Oct 12, 2015 at 9:37 PM Adam Klein  wrote:

> Which sorts of threads are expected to be interruptable? Clearly the
> parser isn't (currently) interruptable in this way, since it takes in a
> stack limit at construction time and never re-sets it.
>
> I guess the question is: is interruptability something that _all_
> AstVisitors should have, with a few exceptions? Or is it something that a
> few AstVisitors care about, but most don't need to. Answering this question
> will help decide what the right way of refactoring the base class stuff is.
>
> On Mon, Oct 12, 2015 at 12:31 PM, Jochen Eisinger 
> wrote:
>
>> We use the stack limit to request interrupts from different threads, so
>> checking it on a regular basis is important
>>
>> On Mon, Oct 12, 2015, 9:30 PM Adam Klein  wrote:
>>
>>> Any thoughts here? Caitlin is currently running into exactly the same
>>> need in her do expression patch, so it'd be good to understand if we can do
>>> something general here instead of having most AST visitors be Isolate-bound
>>> while the few used from the parser need special duplicated code for stack
>>> check handling.
>>>
>>> On Tue, Oct 6, 2015 at 4:17 PM, Adam Klein  wrote:
>>>
>>>> In trying to use AstExpressionVisitor in the parser, I've found the
>>>> need to use an AST visitor where I don't have an Isolate handy. The
>>>> DEFINE_AST_VISITOR_SUBCLASS_MEMBERS macro uses the Isolate for exactly one
>>>> thing (in the method CheckStackOverflow):
>>>>
>>>> ...
>>>> StackLimitCheck check(isolate_);
>>>> if (!check.HasOverflowed()) return false;
>>>> ...
>>>>
>>>> My question is this: is it important that the StackLimitCheck pull the
>>>> stack limit out of the isolate every time CheckStackOverflow() is called?
>>>> Or could we store the stack limit when AST visitors are constructed? The
>>>> latter is what we already do for parsing, in ParseInfo. And from poking
>>>> around the code (and in Blink) it seems like we generally only set the
>>>> stack limit at thread startup. But I'm wondering if there are cases I'm not
>>>> thinking about (maybe cases where a single AST visitor is used on multiple
>>>> threads with the same Isolate?).
>>>>
>>>> - Adam
>>>>
>>>
>>> --
>>> --
>>> v8-dev mailing list
>>> v8-dev@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.
>>>
>> --
>> --
>> v8-dev mailing list
>> v8-dev@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.
>>
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Re: Stack limits and AST visitors

[Jochen Eisinger]

We use the stack limit to request interrupts from different threads, so
checking it on a regular basis is important

On Mon, Oct 12, 2015, 9:30 PM Adam Klein  wrote:

> Any thoughts here? Caitlin is currently running into exactly the same need
> in her do expression patch, so it'd be good to understand if we can do
> something general here instead of having most AST visitors be Isolate-bound
> while the few used from the parser need special duplicated code for stack
> check handling.
>
> On Tue, Oct 6, 2015 at 4:17 PM, Adam Klein  wrote:
>
>> In trying to use AstExpressionVisitor in the parser, I've found the need
>> to use an AST visitor where I don't have an Isolate handy. The
>> DEFINE_AST_VISITOR_SUBCLASS_MEMBERS macro uses the Isolate for exactly one
>> thing (in the method CheckStackOverflow):
>>
>> ...
>> StackLimitCheck check(isolate_);
>> if (!check.HasOverflowed()) return false;
>> ...
>>
>> My question is this: is it important that the StackLimitCheck pull the
>> stack limit out of the isolate every time CheckStackOverflow() is called?
>> Or could we store the stack limit when AST visitors are constructed? The
>> latter is what we already do for parsing, in ParseInfo. And from poking
>> around the code (and in Blink) it seems like we generally only set the
>> stack limit at thread startup. But I'm wondering if there are cases I'm not
>> thinking about (maybe cases where a single AST visitor is used on multiple
>> threads with the same Isolate?).
>>
>> - Adam
>>
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: [es6] ignore @@isConcatSpreadable if access check fails (issue 1230793002 by caitpotte...@gmail.com)

[jochen]

include/ lgtm

https://codereview.chromium.org/1230793002/

--
--
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Code structure bikeshed: Where should spec reference implementations live?

[Jochen Eisinger]

dumping everything in objects.cc? really?

On Fri, Sep 25, 2015 at 1:39 PM Benedikt Meurer 
wrote:

> One important bit tho: The (static) methods should be somewhere close the
> classes they relate to, otherwise we just go back to runtime-*.cc.
>
> On Fri, Sep 25, 2015 at 1:37 PM, Benedikt Meurer 
> wrote:
>
>> AFAIK everyone is doing (1) currently, and so at least for now, which is
>> kinda what we agreed on some time ago. I don't see why we have to change
>> that now. I think (3) is essentially (2) with a different directory/base
>> filename, and many people thought that (2) was bad, which AFAIR is why we
>> are at (1) currently. I'm fine with moving objects.cc/.h somewhere else
>> and/or split them up, but I think we should delay that for now. This will
>> just be distracting for the work that has to happen in that area IMHO.
>>
>> On Fri, Sep 25, 2015 at 12:39 PM, 'Andreas Rossberg' via v8-dev <
>> v8-dev@googlegroups.com> wrote:
>>
>>> Some quick thoughts.
>>>
>>> Option (4) is a non-starter. Section numbers are not stable across spec
>>> releases.
>>>
>>> Option (3) doesn't sound bad, although it's not quite clear what the
>>> criteria for putting something into objects vs runtime vs the new dir would
>>> be. If we introduced a third category, not only stuff from runtime but also
>>> significant parts of the logic in objects.cc should naturally move there.
>>> Sounds like a lot of work with unclear benefit.
>>>
>>> Option (1) seems like the most adequate for now.
>>>
>>> IMHO, thinking about a new directory structure is putting the cart
>>> before the horse at this point. It only is interesting as part of a broader
>>> strategy for splitting up objects.h/cc. I don't think we currently have any
>>> plausible plan for that.
>>>
>>> /Andreas
>>>
>>>
>>> On 25 September 2015 at 11:58, Jakob Kummerow 
>>> wrote:
>>>
 As we have discussed at various occasions recently, we generally want
 to move in the direction of having C++ implementations of spec-defined
 behavior. That raises the question of where this code should live.

 As an example of the kind of code we're talking about, consider
 https://codereview.chromium.org/1368753003/diff/1/src/runtime/runtime-object.cc
  *(don't
 panic, runtime-object.cc is not the intended final place for this code to
 live -- the very purpose of this thread is to figure out a better place.)*,
 but there are also other, existing examples (like various ToXXX conversion
 functions, a bunch of things spread across runtime-*.cc, the JS
 implementations littered with runtime calls that we want to replace, ...).

 Options I can think of:

 (1) Put everything into objects.cc.
 + Makes a lot of sense for things like DefineOwnProperty_Array, which
 could just be a static function JSArray::DefineOwnProperty.
 + Is an easy approach in the sense of being consistent with existing
 code structure (is that a good thing?)
 − It's not clear how this approach maps to non-HeapObjects like the new
 class PropertyDescriptor
 − I like having some distinction between high-level spec-defined
 operations like "DefineOwnProperty" and low-level V8 implementation details
 like MigrateToMap -- installing both on the same class JSObject feels like
 a recipe for confusion.
 − objects.h/.cc are too big as it is, IMHO (of course this point is
 moot if/when we split it up)

 (2) Put everything in runtime-*.cc
 + Works, and there's plenty of precedent.
 − AFAIK we have pretty wide consensus that that's not what we want.
 − A concrete technical drawback is a lack of callability from other
 places.

 (3) Create a new directory, put everything there.
 + All reference implementations would be in one place
 + Can use individual files for further grouping if desired. Is that
 desired? What file structure would be good?
 + Personally I think we need more separation of things anyway, this is
 a step in that direction
 • next question: how to call that directory? src/spec/? src/es6/?
 /src/blue/? (blue sheds are nice)
 − For some things it might be unclear where to put them; our
 "abstractions" are (necessarily?) leaky
 − New thing to get used to; inconsistency while it's a work in progress

 (4) Organize by spec chapter, e.g. put OrdinaryDefineOwnProperty into
 src/es2015/ch9/9.1.cc or somesuch
 + If applied consistently, makes it easy to find things that are
 already implemented, which avoids duplication
 − the resulting grouping may or may not make sense (it's up to the spec)
 − ugly

 Personally I'm leaning towards some variant of (3), but I'm open to
 being convinced otherwise. (1) sounds like a temporary solution to me; why
 not go for a longer-term plan right away?

 Thoughts? Other ideas? Indifference?

 --
 --
 v8-dev mailing list
 v8-dev@googlegroups.com

[v8-dev] Re: Prototype CL for faster DOM accessors. (issue 1292283005 by vogelh...@chromium.org)

[jochen]

https://codereview.chromium.org/1292283005/diff/1/src/runtime/runtime-ptr.cc
File src/runtime/runtime-ptr.cc (right):

https://codereview.chromium.org/1292283005/diff/1/src/runtime/runtime-ptr.cc#newcode84
src/runtime/runtime-ptr.cc:84:
RUNTIME_FUNCTION(Runtime_PtrLoadOffsetInt) {
why not PtrTestIntAtOffset() or something?

https://codereview.chromium.org/1292283005/

--
--
v8-dev mailing list
v8-dev@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.

Re: [v8-dev] Code structure bikeshed: Where should spec reference implementations live?

[Jochen Eisinger]

I think (3) would be nice. There's also a bunch of code in api.cc and
execution.cc that could be moved there.

On Fri, Sep 25, 2015 at 11:58 AM Jakob Kummerow 
wrote:

> As we have discussed at various occasions recently, we generally want to
> move in the direction of having C++ implementations of spec-defined
> behavior. That raises the question of where this code should live.
>
> As an example of the kind of code we're talking about, consider
> https://codereview.chromium.org/1368753003/diff/1/src/runtime/runtime-object.cc
>  *(don't
> panic, runtime-object.cc is not the intended final place for this code to
> live -- the very purpose of this thread is to figure out a better place.)*,
> but there are also other, existing examples (like various ToXXX conversion
> functions, a bunch of things spread across runtime-*.cc, the JS
> implementations littered with runtime calls that we want to replace, ...).
>
> Options I can think of:
>
> (1) Put everything into objects.cc.
> + Makes a lot of sense for things like DefineOwnProperty_Array, which
> could just be a static function JSArray::DefineOwnProperty.
> + Is an easy approach in the sense of being consistent with existing code
> structure (is that a good thing?)
> − It's not clear how this approach maps to non-HeapObjects like the new
> class PropertyDescriptor
> − I like having some distinction between high-level spec-defined
> operations like "DefineOwnProperty" and low-level V8 implementation details
> like MigrateToMap -- installing both on the same class JSObject feels like
> a recipe for confusion.
> − objects.h/.cc are too big as it is, IMHO (of course this point is moot
> if/when we split it up)
>
> (2) Put everything in runtime-*.cc
> + Works, and there's plenty of precedent.
> − AFAIK we have pretty wide consensus that that's not what we want.
> − A concrete technical drawback is a lack of callability from other places.
>
> (3) Create a new directory, put everything there.
> + All reference implementations would be in one place
> + Can use individual files for further grouping if desired. Is that
> desired? What file structure would be good?
> + Personally I think we need more separation of things anyway, this is a
> step in that direction
> • next question: how to call that directory? src/spec/? src/es6/?
> /src/blue/? (blue sheds are nice)
> − For some things it might be unclear where to put them; our
> "abstractions" are (necessarily?) leaky
> − New thing to get used to; inconsistency while it's a work in progress
>
> (4) Organize by spec chapter, e.g. put OrdinaryDefineOwnProperty into
> src/es2015/ch9/9.1.cc or somesuch
> + If applied consistently, makes it easy to find things that are already
> implemented, which avoids duplication
> − the resulting grouping may or may not make sense (it's up to the spec)
> − ugly
>
> Personally I'm leaning towards some variant of (3), but I'm open to being
> convinced otherwise. (1) sounds like a temporary solution to me; why not go
> for a longer-term plan right away?
>
> Thoughts? Other ideas? Indifference?
>
> --
> --
> v8-dev mailing list
> v8-dev@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.
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: Fix a segment-fault caused by Value::IntegerValue (issue 1303093004 by pmq2...@gmail.com)

[jochen]

On 2015/09/09 at 23:35:56, info wrote:

https://codereview.chromium.org/1303093004/diff/1/src/api.cc
File src/api.cc (right):



https://codereview.chromium.org/1303093004/diff/1/src/api.cc#newcode3271
src/api.cc:3271: has_pending_exception =
On 2015/09/09 14:16:59, jochen wrote:
> can you pull the if() case in here instead of duplicating the returns?
>
> something like
>
> PREPARE_FOR...
> if (obj->isNumber())
>  num = obj;
> else {
>  has_pending = ...



That pessimizes the common case when the input is a SMI or double.
PREPARE_FOR_EXECUTION_PRIMITIVE mutates a couple of per-isolate data  
structures

and is fairly heavy-weight.

yeah, that's true

lgtm then

https://codereview.chromium.org/1303093004/

--
--
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: Continuing removing deprecated functions from cctests (issue 1331013003 by myth...@google.com)

[jochen]

overall looks good

can you please run tryjobs?

ToLocalChecked() corresponds to FromJust() which checks that the Maybe<>  
value

is "just", so I'd use that where possible.


https://codereview.chromium.org/1331013003/diff/1/test/cctest/test-unscopables-hidden-prototype.cc
File test/cctest/test-unscopables-hidden-prototype.cc (right):

https://codereview.chromium.org/1331013003/diff/1/test/cctest/test-unscopables-hidden-prototype.cc#newcode45
test/cctest/test-unscopables-hidden-prototype.cc:45:
object->SetPrototype(curr_context, hidden_prototype).FromMaybe(false);
On 2015/09/10 at 09:30:16, rmcilroy wrote:

Could you add a CHECK() around this to check the value returned is

true.

Just use .FromJust() that checks internally.

https://codereview.chromium.org/1331013003/diff/1/test/cctest/test-unscopables-hidden-prototype.cc#newcode62
test/cctest/test-unscopables-hidden-prototype.cc:62: .FromMaybe(-1));
On 2015/09/10 at 09:30:16, rmcilroy wrote:

nit - could .FromMaybe(-1) be on the same line as ->Int32Value

couldn't it (or did git cl format do this to you)?

same here... FromJust()

https://codereview.chromium.org/1331013003/

--
--
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: Fix a segment-fault caused by Value::IntegerValue (issue 1303093004 by pmq2...@gmail.com)

[jochen]

thanks for the fix


https://codereview.chromium.org/1303093004/diff/1/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/1303093004/diff/1/src/api.cc#newcode3271
src/api.cc:3271: has_pending_exception =
can you pull the if() case in here instead of duplicating the returns?

something like

PREPARE_FOR...
if (obj->isNumber())
 num = obj;
else {
 has_pending = ...

https://codereview.chromium.org/1303093004/

--
--
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: ArrayBuffers vs External strings

[Jochen Eisinger]

we used to have such a list and that resulted in second long pauses during
gc when traversing the list. Using the map spreads out this work to the
incremental marking, so there are no long pauses anymore.
On Wed, Sep 9, 2015 at 12:41 PM Fedor Indutny  wrote:

> Hello again!
>
> Kindly reminding about this question.
>
> Thank you,
> Fedor.
>
> On Fri, Sep 4, 2015 at 2:06 AM, Fedor Indutny  wrote:
>
>> Hello!
>>
>> This is a follow-up on the discussion started in:
>> https://codereview.chromium.org/1324023007/ .
>>
>> There appears to be a performance regression in the recent v8 versions.
>> From my tests the regression comes from the introduction of the `std::map`s
>> to keep the live array buffers. Iterating over it is pretty much fast, but
>> inserting the buffers into it has non-linear time (because `std::map`s are
>> powered by Red-Black trees), thus slowing the things down.
>>
>> What's really interesting is that External strings solve the same problem
>> differently and (it looks like) more efficiently. They are just using
>> lists, and checking the marks on the list during GC. Insertion into the
>> list is cheap, and can't really outperform the `std::map` insertion.
>> Iteration with reading marks appears to be taking linear time, so it is
>> still better than inserting things into the `std::map`. Even more, we do
>> insertions into the maps during each GC cycle too, so the time is
>> definitely bigger than just for the lists+markings.
>>
>> I suggest to merge these algorithms, and just use one class to manage
>> both of them. In my opinion, the class should be using lists to improve the
>> performance. I'm open to any kind of suggestions, though!
>>
>> Thank you,
>> Fedor.
>>
>
>

-- 
-- 
v8-dev mailing list
v8-dev@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.

[v8-dev] Re: [accessors] second-chance typed array field lookup (issue 1313493005 by fe...@indutny.com)

[jochen]

Jakob, can you take a look please?

https://codereview.chromium.org/1313493005/

--
--
v8-dev mailing list
v8-dev@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.