Subj : Re: global hash table
To   : Shanti Rao <shantirao@yahoo.com>
From : Brendan Eich <brendan@meer.net>
Date : Thu Feb 19 2004 12:28 am

Shanti Rao wrote:

> Hi Brendan,
>
> Why are script_filename_table, deflated_string_cache, etc. global C 
> variables instead of properties of a runtime?


Two questions (etc. doesn't count, you have to be specific), two answers:

1.  script_filename_table is global because script filenames are part of 
a global (per machine) filesystem, so can be shared across runtimes.  A 
lock would be required to serialize critical sections accessing and 
updating the table in the case that the table is in a runtime, so 
there's no locking penalty in using a global instead of a per runtime.  
But since a given filename may be compiled in several runtimes, the 
sharing benefit of a global table favors the global approach over the 
per-runtime way.

2.  deflated_string_cache came in when the very early (1996) 
SpiderMonkey codebase was extended to do Unicode 2 from ISO-Latin-1.  
The existing JS_GetStringBytes API lacks a cx or rt parameter, so there 
is no way a runtime member could be used for the deflated string cache 
(and again, there is a sharing win in the case of two strings in two 
runtimes being deflated -- but the API constraint was the real 
motivating factor, not any sharing benefit).  API compatibility trumps 
anti-global animus.

Why do you ask, anyway?

/be

.