use jshashtable instead of jsdhash in jsscope.cpp and jspropertytree.cpp

RESOLVED FIXED in mozilla14

Status

()

Core
JavaScript Engine
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: brendan, Assigned: terrence)

Tracking

Trunk
mozilla14
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

7 years ago
Nuff said.

/be
(Assignee)

Comment 1

5 years ago
Created attachment 608896 [details] [diff] [review]
v0

This allows us to stop building jsdhash.cpp for SpiderMonkey, but we do have to keep it and keep jsdhash.h in INSTALLED_HEADERS for xpconnect.
Assignee: general → terrence
Status: NEW → ASSIGNED
Attachment #608896 - Flags: review?(jwalden+bmo)
(Assignee)

Comment 2

5 years ago
Created attachment 608899 [details] [diff] [review]
v1: I spoke too soon.

It looks like XPConnect uses the symbols out of libjs.  What an odd build system we have.
Attachment #608896 - Attachment is obsolete: true
Attachment #608899 - Flags: review?(jwalden+bmo)
Attachment #608896 - Flags: review?(jwalden+bmo)
Comment on attachment 608899 [details] [diff] [review]
v1: I spoke too soon.

Review of attachment 608899 [details] [diff] [review]:
-----------------------------------------------------------------

\o/

::: js/src/builtin/TestingFunctions.cpp
@@ +253,1 @@
>      bool                ok;

While you're touching this, mind moving |bool ok;| to the end?  Keep things in an order more conducive to packing, during future changes.

And, hey, let's get rid of the pointless typedef, too.  :-)

@@ -355,5 @@
>  
>      JS_TracerInit(&countTracer.base, JS_GetRuntime(cx), CountHeapNotify);
> -    if (!JS_DHashTableInit(&countTracer.visited, JS_DHashGetStubOps(),
> -                           NULL, sizeof(JSDHashEntryStub),
> -                           JS_DHASH_DEFAULT_CAPACITY(100))) {

Why this change?  Wasn't it much better to spew out three lines of obscure arguments and internal controls to initialize the hashset, versus just doing it in a single line with no arguments?  r-, not hardcore enough.

::: js/src/jsapi.cpp
@@ +2609,5 @@
>      char            edgeName[1];    /* name of the edge from parent->thing
>                                         into thing */
>  };
>  
> +typedef HashSet<void *, PointerHasher<void *, 3>, SystemAllocPolicy> VisitedSet;

Could you file a followup to augment PointerHasher to assert that the zero-bit are actually zero, if the right value of an additional template parameter is specified?  (Or maybe it should always assert, I don't know if there are actually some uses that wouldn't consider non-zero stripped-off bits to be a bug.)

@@ +2758,2 @@
>          return false;
>      }

Remove the {} now, and add a blank line afterward.

@@ +2761,1 @@
>      dtrc.ok = JS_TRUE;

true

@@ +2771,5 @@
>      } else {
>          JS_TraceChildren(&dtrc.base, startThing, startKind);
>      }
>  
> +    size_t depth = 1;

Move this down past the |if|.

::: js/src/jsdbgapi.cpp
@@ +983,3 @@
>      nbytes += sizeof(JSString);
>      nbytes += (atom->length() + 1) * sizeof(jschar);
>      return nbytes;

I'd convert this to a single return statement, with the current line-by-line conceptual splitting of size components.
Attachment #608899 - Flags: review?(jwalden+bmo) → review+
(Assignee)

Comment 4

5 years ago
(In reply to Jeff Walden (:Waldo) (remove +bmo to email) from comment #3)
> While you're touching this, mind moving |bool ok;| to the end?  Keep things
> in an order more conducive to packing, during future changes.

Oh, brilliant.  That's a good tool to have at my disposal.  Thank you!
 
> @@ -355,5 @@
> >  
> >      JS_TracerInit(&countTracer.base, JS_GetRuntime(cx), CountHeapNotify);
> > -    if (!JS_DHashTableInit(&countTracer.visited, JS_DHashGetStubOps(),
> > -                           NULL, sizeof(JSDHashEntryStub),
> > -                           JS_DHASH_DEFAULT_CAPACITY(100))) {
> 
> Why this change?  Wasn't it much better to spew out three lines of obscure
> arguments and internal controls to initialize the hashset, versus just doing
> it in a single line with no arguments?  r-, not hardcore enough.

I'm trying, but Luke keeps r-ing my patches to the new HashTable. :-)
 
> ::: js/src/jsapi.cpp
> Could you file a followup to augment PointerHasher to assert that the
> zero-bit are actually zero, if the right value of an additional template
> parameter is specified?  (Or maybe it should always assert, I don't know if
> there are actually some uses that wouldn't consider non-zero stripped-off
> bits to be a bug.)

You're ruining the mystery!

https://bugzilla.mozilla.org/show_bug.cgi?id=740874
(Assignee)

Comment 5

5 years ago
Created attachment 610933 [details] [diff] [review]
v2: With review feedback

https://tbpl.mozilla.org/?tree=Try&rev=81bf46bed3d1
Attachment #608899 - Attachment is obsolete: true
Attachment #610933 - Flags: review+
(Assignee)

Comment 6

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/a214d423b525
Assignee: terrence → blackconnect
Component: JavaScript Engine → Java-Implemented Plugins
QA Contact: general → blackconnect
Assignee: blackconnect → general
Component: Java-Implemented Plugins → JavaScript Engine
QA Contact: blackconnect → general
Assignee: general → terrence
Target Milestone: --- → mozilla14
(Assignee)

Comment 7

5 years ago
Thanks for the cleanup Andrew!  That was incredibly odd.
https://hg.mozilla.org/mozilla-central/rev/a214d423b525
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.