[v8-users] Interested in helping develop
Accidentally hit the "post" button... I also came up with an optimization of the algorithm for String.prototype.startsWith() that basically, after the check that the search string is longer than the instance string plus the offset, it is simpler and likely quicker to compare it to the equal length substring than to compare each character, starting at the offset, unless the check is coded in C or possibly C++. -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[v8-users] Interested in helping develop
I have some knowledge of JavaScript, and I was wondering what I could help with in the V8 project. I have no professional experience, but I'm going to start college this fall towards a bachelor's in CS. It would definitely help me in getting experience for later on. Another side question is how much of V8's standard JavaScript library is actually implemented in JavaScript? Obvious ones that could be would be Array.prototype.forEach()/every()/etc. as a `for (var i of ...)` -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Intent to ship: ES6 Map & Set
I would also like to point out that the ES6 array and generator comprehensions
are very similar to the already existent Array.prototype.forEach() and
Array.prototype.map() methods, both of which are not the most optimal at this
point. Here's some relatively simple examples of this in ES6:
var x = [1, 2, 3, 4, 5];
x = [for (let i of x) i*i];
// fat arrow function not implemented in any JS engine AFAIK
var x = [1, 2, 3, 4, 5];
x = x.map((i) => i*i);
// valid ES5 and ES6
var x = [1, 2, 3, 4, 5];
x = x.map(function (i) { return i*i; });
These syntax changes all but require more optimization of the algorithms for
the Array.prototype.forEach() and Array.prototype.map() methods.
I don't know, though, if array comprehensions allow for void returns inside the
functions executed, because I haven't really gone in depth into that part of
the spec. I know that Haskell does, but Python doesn't, and I don't know about
any other languages for sure. Also, reading the spec doesn't really hint either
way explicitly in the algorithm, but it implies that it should be possible.
There is no mention of anything wrong with any return that the function called
itself doesn't have errors (aka void and undefined returns might be
permissible... I'll have to check with the mailing list).
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] GNU readline and the GPL license
Also, if one was released with that support, you could just license *that* part under the GPL, with the rest under something else if the primary license isn't compatible. That kind of licensing is actually relatively common practice for proprietary projects using open source software as part of their distributed binaries (e.g. Apple with Safari and multiple parts of OSX, Google with their Drive apps). -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Problem with several threads trying to lock an isolate, and the withdrawal of v8::Locker's preemption
although it's using the same mechanism as the old preemption code used to use, right? But I agree that this is not necessarily going to work forever. Typically, I'd expect an embedder to use multiple isolates if they wish to run script on different threads in parallel. best -jochen On Thu, Jun 12, 2014 at 4:24 AM, Vyacheslav Egorov wrote: > I would like to note that RequestInterrupt was not intended as a > replacement for preemption. We didn't want callback executing any > JavaScript in the interrupted isolate, so we put the following requirement > on the interrupt callback: > > > *Registered |callback| must not reenter interrupted Isolate.* > > This requirement is not checked right now, but neither anything is > guaranteed to work if you try and start executing JavaScript in the > interrupted isolate from the callback or from another thread (by unlocking > isolate in the callback and allowing other thread to lock it). > > > Vyacheslav Egorov > > > On Thu, Jun 12, 2014 at 1:10 PM, juu wrote: > >> Ok, I didn't notice this API available since v8 3.25. >> >> I will have to wait for my team to migrate to a new version of v8 then >> ... >> >> Thanks >> Julien. >> On Thursday, June 12, 2014 1:44:27 AM UTC+2, Jochen Eisinger wrote: >>> >>> >>> >>> >>> On Tue, Jun 10, 2014 at 8:38 AM, juu wrote: >>> Hello everyone, I'm trying to implement RequireJS on my JS Engine based on v8 (v8 3.21). I have a problem with asynchronous loading and evaluation of scripts. The main thread initialize v8 : create its isolate, context, script etc .. When the main script is ready, the current isolate is locked and the script is run. Once a " *require(anotherScript)* " is encoutered (in my main script), another thread is created and is in charge of loading *anotherScript *and execute it as soon as possible. My problem is that the main thread lock the current isolate until the whole main script is executed. Which let no chance to *anotherScript *to be called asynchronously ; actually it's always executed synchronously since *anotherScript *manage to Lock the current isolate only once the main thread is finished and unlock the current isolate. I use v8::Locker and v8::Locker to deal with my "multithreaded" use of v8. In my version of v8 : 3.21, v8::Locker provide a preemption feature which enable me to give some chance to other threads to lock v8 periodically : /**Start preemption.When preemption is started, a timer is fired every n milliseconds that will switch between multiple threads that are in contention for the V8 lock. */ static void StartPreemption(int every_n_ms); /** Stop preemption.*/ static void StopPreemption(); But ...this feature is no longer available in the next versions of v8 (since 3.23) . This post confirm it : https://groups.google.com/ forum/#!searchin/v8-users/StartPreemption/v8-users/ E5jtPC-scp8/H-2yz4Wj_SkJ So here are my questions : Is there any other way to perform the Preemption v8 used to provide ? Am I supposed to do it myself ? I dont think I can, I guess can't interrupt/pause myself the execution properly... >>> >>> I guess you can do this by using the RequestInterrupt API? >>> >>> best >>> -jochen >>> >>> >>> Am I doing something wrong in my global use of v8 and multiple threads ? Thanks a lot ! Julien. -- -- v8-users mailing list v8-u...@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. >>> >>> -- >> -- >> v8-users mailing list >> v8-users@googlegroups.com >> http://groups.google.com/group/v8-users >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to v8-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscr
Re: [v8-users] Re: Many functions memory optimization
And even if function would be considered immutable, and not be objects, you'd have to get rid of the configurable (and also mutable) function.prototype which is closure-specific (and has a backpointer to the closure as .constructor). On Thu, Jun 12, 2014 at 3:00 PM, 'Andreas Rossberg' via v8-users < v8-users@googlegroups.com> wrote: > On 12 June 2014 14:33, Sven Panne wrote: > > Just a quick note: This has nothing to do with closures, it is a > consequence > > of the spec requirement that functions are mutable objects in JavaScript. > > You can e.g. assign properties to them, mutate those properties, etc. So > > every spec conforming implementation *has to* create a new function > object > > (unless it can prove that the program doesn't use this aspect of the > > function object in question, which is impossible in general). > > Nit: Even if they were immutable, as long as functions are considered > objects (a terrible idea to boot) they have identity, and all > potential optimisations are generally out the window already. > > Mutability implies the need for identity, but it's really identity > that is the core problem. > > /Andreas > > -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[v8-users] Previous value in interceptors
Hi there, I am writing some interceptor code for my objects, and I was wondering, whether it was possible to know, what was the *previous* value for the property, before it's overwritten by args.GetReturnValue().*Set*(whatever). I need something like args.GetReturnValue().*Get*(), but there is no such method. Thanks in advance, Danny -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Re: Many functions memory optimization
On 12 June 2014 14:33, Sven Panne wrote: > Just a quick note: This has nothing to do with closures, it is a consequence > of the spec requirement that functions are mutable objects in JavaScript. > You can e.g. assign properties to them, mutate those properties, etc. So > every spec conforming implementation *has to* create a new function object > (unless it can prove that the program doesn't use this aspect of the > function object in question, which is impossible in general). Nit: Even if they were immutable, as long as functions are considered objects (a terrible idea to boot) they have identity, and all potential optimisations are generally out the window already. Mutability implies the need for identity, but it's really identity that is the core problem. /Andreas -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Re: Many functions memory optimization
On Thu, Jun 12, 2014 at 1:51 PM, Jakob Kummerow
wrote:
> Right. "Closure" is a bit of an overloaded term. I meant function objects
> (or "instances" if you prefer). Even if they don't access variables from
> their outer scope, by executing "foo = function() {...}" every time the
> constructor runs, you'll get a new function object (i.e. a new "closure")
> every time. [...]
>
Just a quick note: This has nothing to do with closures, it is a
consequence of the spec requirement that functions are mutable objects in
JavaScript. You can e.g. assign properties to them, mutate those
properties, etc. So every spec conforming implementation *has to* create a
new function object (unless it can prove that the program doesn't use this
aspect of the function object in question, which is impossible in general).
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Re: Many functions memory optimization
On Thu, Jun 12, 2014 at 12:59 PM, Ben Noordhuis wrote:
> On Thu, Jun 12, 2014 at 12:18 PM, Ilya Kantor wrote:
> > Do I get it right that unoptimized code is shared but optimize code is
> not
> > (or shared partially or...)?
>
As I said, in some cases it is shared, but in others it is not (the details
are technical and might change).
> >
> > If closure is the root of all evil, will it help with sharing if I remove
> > the closure completely?
>
> Not quite. What I think Jacob tried to convey is that a closure
> basically looks like this:
>
> struct Closure {
> Function* function;
> Context* context;
> };
Right. "Closure" is a bit of an overloaded term. I meant function objects
(or "instances" if you prefer). Even if they don't access variables from
their outer scope, by executing "foo = function() {...}" every time the
constructor runs, you'll get a new function object (i.e. a new "closure")
every time.
> Each closure has its own context object but they all start out with
> the same non-optimized function.
>
> If you have three identical closures and call one of them a million
> times, V8 will eventually optimize it and update the closure object to
> make it point to the new, optimized function. The other two will
> still be pointing to the non-optimized version at that point.
>
> If you then start calling the second closure frequently, the optimizer
> is going to discover that it already has an optimized function for
> this kind of closure and update the closure object accordingly.
>
> > Like this:
> > ```
> > function Machine(power) {
> >
> > this.enable = function() {
> > this._enabled = true;
> > };
> > this.disable = function() {
> > this._enabled = false;
> > };
> > }
> >
> > var machines = []
> > for(var i=0; i<1; i++) machines.push(new Machine)
> > ```
>
> I believe you should unconditionally set `this._enabled = false` (or
> true) in the constructor to prevent unnecessary hidden class
> transitions.
>
Definitely!
> I'm not 100% sure if it matters in this particular example so someone
> please correct me if I'm wrong.
>
Whether it matters for performance in any given case can only be determined
by measuring (and depends on surrounding code), but it's a very good rule
of thumb.
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Problem with several threads trying to lock an isolate, and the withdrawal of v8::Locker's preemption
I would like to note that RequestInterrupt was not intended as a replacement for preemption. We didn't want callback executing any JavaScript in the interrupted isolate, so we put the following requirement on the interrupt callback: *Registered |callback| must not reenter interrupted Isolate.* This requirement is not checked right now, but neither anything is guaranteed to work if you try and start executing JavaScript in the interrupted isolate from the callback or from another thread (by unlocking isolate in the callback and allowing other thread to lock it). Vyacheslav Egorov On Thu, Jun 12, 2014 at 1:10 PM, juu wrote: > Ok, I didn't notice this API available since v8 3.25. > > I will have to wait for my team to migrate to a new version of v8 then ... > > Thanks > Julien. > On Thursday, June 12, 2014 1:44:27 AM UTC+2, Jochen Eisinger wrote: >> >> >> >> >> On Tue, Jun 10, 2014 at 8:38 AM, juu wrote: >> >>> Hello everyone, >>> >>> I'm trying to implement RequireJS on my JS Engine based on v8 (v8 3.21). >>> I have a problem with asynchronous loading and evaluation of scripts. >>> >>> The main thread initialize v8 : create its isolate, context, script etc >>> .. >>> When the main script is ready, the current isolate is locked and the >>> script is run. >>> >>> Once a " *require(anotherScript)* " is encoutered (in my main script), >>> another thread is created and is in charge of loading *anotherScript *and >>> execute it as soon as possible. >>> >>> My problem is that the main thread lock the current isolate until the >>> whole main script is executed. Which let no chance to *anotherScript *to >>> be called asynchronously ; actually it's always executed synchronously >>> since *anotherScript *manage to Lock the current isolate only once the >>> main thread is finished and unlock the current isolate. >>> >>> I use v8::Locker and v8::Locker to deal with my "multithreaded" use of >>> v8. In my version of v8 : 3.21, v8::Locker provide a preemption feature >>> which enable me to give some chance to other threads to lock v8 >>> periodically : >>> >>> /**Start preemption.When preemption is started, a timer is fired every n >>> milliseconds that will switch between multiple threads that are in >>> contention for the V8 lock. */ >>> static void StartPreemption(int every_n_ms); >>> >>> /** Stop preemption.*/ >>> static void StopPreemption(); >>> >>> But ...this feature is no longer available in the next versions of v8 >>> (since 3.23) . >>> This post confirm it : https://groups.google.com/ >>> forum/#!searchin/v8-users/StartPreemption/v8-users/ >>> E5jtPC-scp8/H-2yz4Wj_SkJ >>> >>> So here are my questions : >>> >>> Is there any other way to perform the Preemption v8 used to provide ? >>> Am I supposed to do it myself ? I dont think I can, I guess can't >>> interrupt/pause myself the execution properly... >>> >> >> I guess you can do this by using the RequestInterrupt API? >> >> best >> -jochen >> >> >> >>> Am I doing something wrong in my global use of v8 and multiple threads ? >>> >>> >>> Thanks a lot ! >>> Julien. >>> >>> -- >>> -- >>> v8-users mailing list >>> v8-u...@googlegroups.com >>> >>> http://groups.google.com/group/v8-users >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to v8-users+u...@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Problem with several threads trying to lock an isolate, and the withdrawal of v8::Locker's preemption
Ok, I didn't notice this API available since v8 3.25. I will have to wait for my team to migrate to a new version of v8 then ... Thanks Julien. On Thursday, June 12, 2014 1:44:27 AM UTC+2, Jochen Eisinger wrote: > > > > > On Tue, Jun 10, 2014 at 8:38 AM, juu > > wrote: > >> Hello everyone, >> >> I'm trying to implement RequireJS on my JS Engine based on v8 (v8 3.21). >> I have a problem with asynchronous loading and evaluation of scripts. >> >> The main thread initialize v8 : create its isolate, context, script etc >> .. >> When the main script is ready, the current isolate is locked and the >> script is run. >> >> Once a " *require(anotherScript)* " is encoutered (in my main script), >> another thread is created and is in charge of loading *anotherScript *and >> execute it as soon as possible. >> >> My problem is that the main thread lock the current isolate until the >> whole main script is executed. Which let no chance to *anotherScript *to >> be called asynchronously ; actually it's always executed synchronously >> since *anotherScript *manage to Lock the current isolate only once the >> main thread is finished and unlock the current isolate. >> >> I use v8::Locker and v8::Locker to deal with my "multithreaded" use of >> v8. In my version of v8 : 3.21, v8::Locker provide a preemption feature >> which enable me to give some chance to other threads to lock v8 >> periodically : >> >> /**Start preemption.When preemption is started, a timer is fired every n >> milliseconds that will switch between multiple threads that are in >> contention for the V8 lock. */ >> static void StartPreemption(int every_n_ms); >> >> /** Stop preemption.*/ >> static void StopPreemption(); >> >> But ...this feature is no longer available in the next versions of v8 >> (since 3.23) . >> This post confirm it : >> https://groups.google.com/forum/#!searchin/v8-users/StartPreemption/v8-users/E5jtPC-scp8/H-2yz4Wj_SkJ >> >> So here are my questions : >> >> Is there any other way to perform the Preemption v8 used to provide ? >> Am I supposed to do it myself ? I dont think I can, I guess can't >> interrupt/pause myself the execution properly... >> > > I guess you can do this by using the RequestInterrupt API? > > best > -jochen > > > >> Am I doing something wrong in my global use of v8 and multiple threads ? >> >> Thanks a lot ! >> Julien. >> >> -- >> -- >> v8-users mailing list >> v8-u...@googlegroups.com >> http://groups.google.com/group/v8-users >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to v8-users+u...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] Re: Many functions memory optimization
On Thu, Jun 12, 2014 at 12:18 PM, Ilya Kantor wrote:
> Do I get it right that unoptimized code is shared but optimize code is not
> (or shared partially or...)?
>
> If closure is the root of all evil, will it help with sharing if I remove
> the closure completely?
Not quite. What I think Jacob tried to convey is that a closure
basically looks like this:
struct Closure {
Function* function;
Context* context;
};
Each closure has its own context object but they all start out with
the same non-optimized function.
If you have three identical closures and call one of them a million
times, V8 will eventually optimize it and update the closure object to
make it point to the new, optimized function. The other two will
still be pointing to the non-optimized version at that point.
If you then start calling the second closure frequently, the optimizer
is going to discover that it already has an optimized function for
this kind of closure and update the closure object accordingly.
> Like this:
> ```
> function Machine(power) {
>
> this.enable = function() {
> this._enabled = true;
> };
> this.disable = function() {
> this._enabled = false;
> };
> }
>
> var machines = []
> for(var i=0; i<1; i++) machines.push(new Machine)
> ```
I believe you should unconditionally set `this._enabled = false` (or
true) in the constructor to prevent unnecessary hidden class
transitions.
I'm not 100% sure if it matters in this particular example so someone
please correct me if I'm wrong.
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[v8-users] Re: Many functions memory optimization
>
>
>
Hi,
Do I get it right that unoptimized code is shared but optimize code is not
(or shared partially or...)?
If closure is the root of all evil, will it help with sharing if I remove
the closure completely?
Like this:
```
function Machine(power) {
this.enable = function() {
this._enabled = true;
};
this.disable = function() {
this._enabled = false;
};
}
var machines = []
for(var i=0; i<1; i++) machines.push(new Machine)
```
>
> When I create many objects new Machine like this
> ```
> function Machine(power) {
> var enabled = false;
>
> this.enable = function() {
> enabled = true;
> };
> this.disable = function() {
> enabled = false;
> };
> }
>
> var machines = []
> for(var i=0; i<1; i++) machines.push(new Machine)
> ```
>
> ...I see in Chrome Heap Profile that every object has 36 bytes for
> function enable/disable.
> That is so even if the function code is actually longer.
>
> Do I get it right that V8 actually creates these functions only ONE time
> and uses it for all machines?
>
>
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
