On Monday, November 5, 2012 10:28:57 AM UTC+1, Joran Dirk Greef wrote:

> Recent GC changes in V8 are wreaking havoc with a production app. GC
> traces are showing pauses of over 22 seconds. Recent GC changes are unable
> to handle millions of long-lived entities.

> V8 3.6.6.25 GC works perfectly.

> The one problem now is getting V8 3.6.6.25 to allow max-old-space-size
> greater than 1900 MB on Ubuntu.

> Is there any way to run V8 3.6.6.25 with max-old-space-size greater than
> 1900 MB?

> Or is there a slightly newer version than 3.6.6.25 which allows bigger
> heaps but without all the new GC work?

> Your help would be much appreciated.

> Recent GC changes are unable to handle millions of long-lived entities. V8 3.6.6.25 GC works perfectly.

> Recent GC changes in V8 are wreaking havoc with a production app. GC traces
> are showing pauses of over 22 seconds. Recent GC changes are unable to
> handle millions of long-lived entities.

> V8 3.6.6.25 GC works perfectly.

> The one problem now is getting V8 3.6.6.25 to allow max-old-space-size
> greater than 1900 MB on Ubuntu.

> Is there any way to run V8 3.6.6.25 with max-old-space-size greater than
> 1900 MB?

> Or is there a slightly newer version than 3.6.6.25 which allows bigger heaps
> but without all the new GC work?

> Your help would be much appreciated.

> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users

On Monday, November 5, 2012 4:53:59 PM UTC+2, Vyacheslav Egorov wrote:

> > Recent GC changes are unable to handle millions of long-lived entities.
> V8 3.6.6.25 GC works perfectly.

> Contrary to what you might think worst pause time for V8 3.6.x and V8
> 3.7 - 3.15 should be roughly the same. V8 3.7 will also do 7 GCs in a
> row as a last resort.

> However in 3.6 if you hit a full collection it will always pause your
> app for much longer then a incremental collector of 3.7 and later
> would (given that everything is tweaked correctly).

> --
> Vyacheslav Egorov

> On Mon, Nov 5, 2012 at 1:28 AM, Joran Dirk Greef <jo...@ronomon.com<javascript:>>
> wrote:
> > Recent GC changes in V8 are wreaking havoc with a production app. GC
> traces
> > are showing pauses of over 22 seconds. Recent GC changes are unable to
> > handle millions of long-lived entities.

> > V8 3.6.6.25 GC works perfectly.

> > The one problem now is getting V8 3.6.6.25 to allow max-old-space-size
> > greater than 1900 MB on Ubuntu.

> > Is there any way to run V8 3.6.6.25 with max-old-space-size greater than
> > 1900 MB?

> > Or is there a slightly newer version than 3.6.6.25 which allows bigger
> heaps
> > but without all the new GC work?

> > Your help would be much appreciated.

> > --
> > v8-users mailing list
> > v8-u...@googlegroups.com <javascript:>
> > http://groups.google.com/group/v8-users

> In practice it's working perfectly now. I rolled Node from v0.8 back to v0.6
> and the false positive allocation errors are no longer happening. There's no
> more "last resort gc". Load has dropped from 100% to 1%. The gc trace looks
> normal now. I assumed the GC errors were due to the different version of V8
> bundled with Node. Perhaps it's something in Node triggering full GC
> repetitively? Would Node trigger GC by itself?

> On Monday, November 5, 2012 4:53:59 PM UTC+2, Vyacheslav Egorov wrote:

>> > Recent GC changes are unable to handle millions of long-lived entities.
>> > V8 3.6.6.25 GC works perfectly.

>> Contrary to what you might think worst pause time for V8 3.6.x and V8
>> 3.7 - 3.15 should be roughly the same. V8 3.7 will also do 7 GCs in a
>> row as a last resort.

>> However in 3.6 if you hit a full collection it will always pause your
>> app for much longer then a incremental collector of 3.7 and later
>> would (given that everything is tweaked correctly).

>> --
>> Vyacheslav Egorov

>> On Mon, Nov 5, 2012 at 1:28 AM, Joran Dirk Greef <jo...@ronomon.com>
>> wrote:
>> > Recent GC changes in V8 are wreaking havoc with a production app. GC
>> > traces
>> > are showing pauses of over 22 seconds. Recent GC changes are unable to
>> > handle millions of long-lived entities.

>> > V8 3.6.6.25 GC works perfectly.

>> > The one problem now is getting V8 3.6.6.25 to allow max-old-space-size
>> > greater than 1900 MB on Ubuntu.

>> > Is there any way to run V8 3.6.6.25 with max-old-space-size greater than
>> > 1900 MB?

>> > Or is there a slightly newer version than 3.6.6.25 which allows bigger
>> > heaps
>> > but without all the new GC work?

>> > Your help would be much appreciated.

>> > --
>> > v8-users mailing list
>> > v8-u...@googlegroups.com
>> > http://groups.google.com/group/v8-users

> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users

> Node should not be able to trigger last resort gc.

> It can be that recent changes in V8 changed allocation patterns for
> some large object (array, properties backing store etc) and this now
> causes last resort GC to happen.

> Unfortunately it is impossible to figure out what is going on unless
> you can somehow get a back trace from inside
> CollectAllAvailableGarbage.

> --
> Vyacheslav Egorov

> On Mon, Nov 5, 2012 at 7:08 AM, Joran Dirk Greef <jo...@ronomon.com> wrote:
>> In practice it's working perfectly now. I rolled Node from v0.8 back to v0.6
>> and the false positive allocation errors are no longer happening. There's no
>> more "last resort gc". Load has dropped from 100% to 1%. The gc trace looks
>> normal now. I assumed the GC errors were due to the different version of V8
>> bundled with Node. Perhaps it's something in Node triggering full GC
>> repetitively? Would Node trigger GC by itself?

>> On Monday, November 5, 2012 4:53:59 PM UTC+2, Vyacheslav Egorov wrote:

>>>> Recent GC changes are unable to handle millions of long-lived entities..
>>>> V8 3.6.6.25 GC works perfectly.

>>> Contrary to what you might think worst pause time for V8 3.6.x and V8
>>> 3.7 - 3.15 should be roughly the same. V8 3.7 will also do 7 GCs in a
>>> row as a last resort.

>>> However in 3.6 if you hit a full collection it will always pause your
>>> app for much longer then a incremental collector of 3.7 and later
>>> would (given that everything is tweaked correctly).

On Mon, Nov 5, 2012 at 8:17 AM, Joran Greef <jo...@ronomon.com> wrote:
> How can I get such a back trace?

> On 05 Nov 2012, at 6:14 PM, v8-users@googlegroups.com wrote:

>> Node should not be able to trigger last resort gc.

>> It can be that recent changes in V8 changed allocation patterns for
>> some large object (array, properties backing store etc) and this now
>> causes last resort GC to happen.

>> Unfortunately it is impossible to figure out what is going on unless
>> you can somehow get a back trace from inside
>> CollectAllAvailableGarbage.

>> --
>> Vyacheslav Egorov

>> On Mon, Nov 5, 2012 at 7:08 AM, Joran Dirk Greef <jo...@ronomon.com> wrote:
>>> In practice it's working perfectly now. I rolled Node from v0.8 back to v0.6
>>> and the false positive allocation errors are no longer happening. There's no
>>> more "last resort gc". Load has dropped from 100% to 1%. The gc trace looks
>>> normal now. I assumed the GC errors were due to the different version of V8
>>> bundled with Node. Perhaps it's something in Node triggering full GC
>>> repetitively? Would Node trigger GC by itself?

>>> On Monday, November 5, 2012 4:53:59 PM UTC+2, Vyacheslav Egorov wrote:

>>>>> Recent GC changes are unable to handle millions of long-lived entities..
>>>>> V8 3.6.6.25 GC works perfectly.

>>>> Contrary to what you might think worst pause time for V8 3.6.x and V8
>>>> 3.7 - 3.15 should be roughly the same. V8 3.7 will also do 7 GCs in a
>>>> row as a last resort.

>>>> However in 3.6 if you hit a full collection it will always pause your
>>>> app for much longer then a incremental collector of 3.7 and later
>>>> would (given that everything is tweaked correctly).

> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users