On 2/7/14 6:56 AM, Branislav Rankov wrote:
I am not able to assign this patch to myself. Can someone do it for me?
I see this has been done, but I just gave you editbugs/canconfirm bits
so you can make the normal range of changes to bugs that any regular
developer can make. :-)
Jeff
__
On Fri, Feb 7, 2014 at 2:52 PM, Nicholas Nethercote
wrote:
>
> If you choose to atomize a char sequence, it incurs costs.
>
> 1. Time: you have to check if the char sequence has been previously
> atomized. In our implementation, this involves a hash table lookup,
> which includes a hash computatio
For my own elucidation...
If you choose to atomize a char sequence, it incurs costs.
1. Time: you have to check if the char sequence has been previously
atomized. In our implementation, this involves a hash table lookup,
which includes a hash computation.
2. Time: the GC has to deal with the ato
On Fri, Feb 7, 2014 at 1:40 PM, Kannan Vijayan wrote:
>>
>> However, it's not the only cost -- there's also the hashing (time)
>> cost. For very long strings this cost is high. I wonder if we should
>> change AtomHasher to look at only the first N and last N chars in the
>> string when computing t
On 2/7/14 4:40 PM, Kannan Vijayan wrote:
Not hashing the entire string sounds like a collision attack vector.
Are we talking about not using the whole string when computing the
hashcode or about not using the whole string for the equality compare on
collisions?
It sounded to me like Nichola
On 2/7/2014, 4:11 PM, Nicholas Nethercote wrote:
On Fri, Feb 7, 2014 at 8:31 AM, Kannan Vijayan wrote:
Atomizing string literals is definitely a good idea, although it might make
sense to put a length limit - say 32 or 64 chars (do we already do this,
maybe?).
We don't. If there were some plac
On Fri, Feb 7, 2014 at 8:31 AM, Kannan Vijayan wrote:
>
> Atomizing string literals is definitely a good idea, although it might make
> sense to put a length limit - say 32 or 64 chars (do we already do this,
> maybe?).
We don't. If there were some places where we might atomize and might
not, the
On Fri, Feb 7, 2014 at 6:06 AM, Jan de Mooij wrote:
>
> Atoms also make string comparisons fast
> [...]
> String equality is also easy for the JITs to inline when you have two
> atoms
Ah, yes. Thanks!
Nick
___
dev-tech-js-engine-internals mailing list
String literals are used heavily in run-time reflection, e.g.:
Object.getOwnPropertyDescriptor(obj, 'foo')
typeof(x) === "object")
String literals are also used to represent symbolic values in JS. It's
not uncommon to see things like:
var Days = { Monday:'Monday', Tuesday:'Tuesday', ...
I have created a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=969375
I have submitted the first patch. It is a small patch since today is
Friday :)
I am not able to assign this patch to myself. Can someone do it for me?
Regards,
Branislav Rankov
_
On Fri, Feb 7, 2014 at 2:59 PM, Branislav Rankov
wrote:
> So, what is the first step? Should I create a bug on Bugzilla? Or does
> someone else want to take the honour?
Yes, please file a bug in the "JavaScript Engine: JIT" component.
Since you did all the work it's probably best if you file it :
On Fri, Feb 7, 2014 at 2:34 PM, Nicholas Nethercote
wrote:
> A more general question: what exactly is atomization for? Is it purely
> for cases where we want to avoid duplicating strings (with the option
> of interning)? The fact that lots of data structures (e.g. ParseNode)
> have JSAtom* fields
On 02/07/2014 10:18 AM, Jan de Mooij wrote:
As small as possible. It's usually easier to review many small patches
than 1 big patch.
I will try to make the patches as small as possible.
So, what is the first step? Should I create a bug on Bugzilla? Or does
someone else want to take the honou
Hi,
During tokenization, we atomize identifiers. This makes sense to me,
because identifiers are almost certain to appear multiple times.
But we also atomize string literals. These are much less likely to
appear multiple times. Is it necessary?
A more general question: what exactly is atomizatio
On Friday, February 7, 2014 10:18:57 AM UTC+1, Jan de Mooij wrote:
> There's a (Chinese) company working on MIPS support as well. Are they
>
> related to you in any way? If not, hopefully you will be able to
>
> collaborate; I sent them a link to this thread so that they can
>
> contact you.
>
Hi,
There's a (Chinese) company working on MIPS support as well. Are they
related to you in any way? If not, hopefully you will be able to
collaborate; I sent them a link to this thread so that they can
contact you.
On Thu, Feb 6, 2014 at 10:36 PM, Branislav Rankov
wrote:
> 1. Would you like to
Thats great. Thanks for the clarification! It's great to upstream MIPS
support into gecko.
Andreas
Sent from Mobile.
> On Feb 7, 2014, at 8:43, Branislav Rankov wrote:
>
> Hi Andreas,
>
> Thanks for offering to be a reviewer.
>
> We are not inventing a new simulator for MIPS. We are porting the
Hi Andreas,
Thanks for offering to be a reviewer.
We are not inventing a new simulator for MIPS. We are porting the
simulator from v8. Similarly to the one that is ported for ARM.
Regards,
Branislav Rankov
On 02/07/2014 04:27 AM, Andreas Gal wrote:
I am going to regret saying this but I am
18 matches
Mail list logo
