On Tue, Dec 11, 2012 at 1:11 PM, Terrence Cole wrote:
> I'm hoping Nicolas, David, or Brian can chime in here with a more
> nuanced explanation of how IonBuilder should be interacting with the GC:
> I'm not an expert in this area of code.
My opinion is that we should never GC during analysis or c
On 12/11/2012 12:11 PM, Terrence Cole wrote:
On 12/11/2012 11:40 AM, Brendan Eich wrote:
Terrence Cole wrote:
I'm also still working on getting the Shape changes landed: turns out
more of the paths through IonBuilder can GC than I thought.
Can't we just disable GC when in IonBuilder?
/be
T
On 12/10/2012 10:02 PM, Norbert Lindenberg wrote:
> a) Should we follow established JavaScript conventions and allow only
> constructor and namespace names to start with a capital letter (i.e., Array
> and Intl)? Or should we follow the SpiderMonkey C/C++ conventions, which
> allow other functio
On 12/11/2012 11:40 AM, Brendan Eich wrote:
> Terrence Cole wrote:
>> I'm also still working on getting the Shape changes landed: turns out
>> more of the paths through IonBuilder can GC than I thought.
>
> Can't we just disable GC when in IonBuilder?
>
> /be
The reason I made these so aggressiv
Terrence Cole wrote:
I'm also still working on getting the Shape changes landed: turns out
more of the paths through IonBuilder can GC than I thought.
Can't we just disable GC when in IonBuilder?
/be
___
dev-tech-js-engine-internals mailing list
dev-
Sorry this is a bit late. Steve has been working on improving the script
by adding the delta from each prior week. I was holding off for that,
but there is no reason not to put the raw numbers here in the meantime.
++
| m-i/js/src |
++
jsval : 1062
Value
The macros might not really be worth it, I never thoroughly tested, to
be honest.
On the other hand, the JITs have heuristics for when to inline, and
calling more functions makes them less likely to inline the main
function itself. But again: I don't know enough about the JITs to
really know this.
Le 11/12/2012 16:10, Till Schneidereit a écrit :
b) Should the names of macros indicate how they're implemented or should they
just look like other functions?
Just a quick explanation for this: the script that embeds self-hosted
JS invokes a Python script, builtins/macros.py, that replaces some
> b) Should the names of macros indicate how they're implemented or should they
> just look like other functions?
Just a quick explanation for this: the script that embeds self-hosted
JS invokes a Python script, builtins/macros.py, that replaces some
constructs such as IS_UNDEFINED by proper JS c
Le 11/12/2012 04:02, Norbert Lindenberg a écrit :
Till, Jeff, and I had some discussion about naming conventions for self-hosted
JavaScript - would be good to get input from others. I tossed in a few more
cases that I've come across.
a) Should we follow established JavaScript conventions and a
10 matches
Mail list logo
