Bug 185931 – Make JSC have a mini mode that kicks in when the JIT is disabled

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Saam Barati]

...

[Saam Barati]

Created attachment 341322 [details]
patch

[Mark Lam]

Comment on attachment 341322 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=341322&action=review

r=me

> Source/JavaScriptCore/ChangeLog:11
> +        - We always sweep synchronously.

You should also add "disable generational GC" because that's what the code below does.

[Saam Barati]

Comment on attachment 341322 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=341322&action=review

>> Source/JavaScriptCore/ChangeLog:11
>> +        - We always sweep synchronously.
> 
> You should also add "disable generational GC" because that's what the code below does.

Will do

[Saam Barati]

landed in:
https://trac.webkit.org/changeset/232210/webkit

[Radar WebKit Bug Importer]

<rdar://problem/40568609>

[Basuke Suzuki]

Comment on attachment 341322 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=341322&action=review

> Source/JavaScriptCore/heap/Heap.cpp:131
> +        return Options::miniVMHeapGrowthFactor() * heapSize;

Question. What is the reason to use fixed growth factor here for mini mode? I guess that is because mini mode returns memory to the system more than other environment. Are there any other reason for specific platform? i.e. WatchOS?

[Saam Barati]

(In reply to Basuke Suzuki from comment #6)
> Comment on attachment 341322 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=341322&action=review
> 
> > Source/JavaScriptCore/heap/Heap.cpp:131
> > +        return Options::miniVMHeapGrowthFactor() * heapSize;
> 
> Question. What is the reason to use fixed growth factor here for mini mode?
> I guess that is because mini mode returns memory to the system more than
> other environment. Are there any other reason for specific platform? i.e.
> WatchOS?

We currently only tie this to running with the JIT or not.

You could imagine implementing this in other ways. The main idea here is that when you run without the JIT, your rate of allocation is smaller. So you can afford to be more aggressive about collecting.

IIRC, the main idea was to have:
GC % = (time running GC) / (time running code)

to be more or less the constant irrespective of using the JIT or not. If we kept the non-mini mode growth factors, we'd have decreased our GC%.

[Basuke Suzuki]

Saam,

> We currently only tie this to running with the JIT or not.
> 
> You could imagine implementing this in other ways. The main idea here is
> that when you run without the JIT, your rate of allocation is smaller. So
> you can afford to be more aggressive about collecting.

Make sense.

> IIRC, the main idea was to have:
> GC % = (time running GC) / (time running code)
> 
> to be more or less the constant irrespective of using the JIT or not. If we
> kept the non-mini mode growth factors, we'd have decreased our GC%.

Thanks. The idea above is very reasonable. We start with this rate and if we find a better number for our platform, we'll think about that.