Last Comment Bug 744192 - GC: ensure there are no implicit post barriers in a Vector
: GC: ensure there are no implicit post barriers in a Vector
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla14
Assigned To: Terrence Cole [:terrence]
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: 673454
  Show dependency treegraph
Reported: 2012-04-10 14:37 PDT by Terrence Cole [:terrence]
Modified: 2012-04-12 10:22 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

v0 (4.19 KB, patch)
2012-04-10 14:37 PDT, Terrence Cole [:terrence]
luke: review+
Details | Diff | Splinter Review
v1: Carrying review forward, since Luke gave me the working solution. :-) (3.68 KB, patch)
2012-04-11 17:15 PDT, Terrence Cole [:terrence]
terrence.d.cole: review+
Details | Diff | Splinter Review

Description Terrence Cole [:terrence] 2012-04-10 14:37:54 PDT
Created attachment 613773 [details] [diff] [review]

If we store an implicitly post barriered type in a vector, we will fall over when the vector relocates our storage.  This patch simply asserts that we do not have any.  We still compile with this and grepping for "Vector<Heap" did not turn up any results, so I think we are in the clear with these.  This assertion will ensure that we stay in the clear going forward.
Comment 1 Luke Wagner [:luke] 2012-04-10 15:03:39 PDT
Comment on attachment 613773 [details] [diff] [review]

Review of attachment 613773 [details] [diff] [review]:

::: js/public/Vector.h
@@ +284,5 @@
>      Vector &operator=(const Vector &) MOZ_DELETE;
> +    void checkStaticInvarients() {
> +        JS_STATIC_ASSERT(!tl::IsPostBarrieredType<T>::result);
> +    }

I usually make these things 'static'

@@ +534,5 @@
>  #ifdef DEBUG
>    , mReserved(0), entered(false)
>  #endif
> +{
> +    checkStaticInvarients();

I don't think you need to call it to get the static checks.
Comment 2 Terrence Cole [:terrence] 2012-04-10 16:52:01 PDT

With review comments _not_ applied, as per our IRC conversation.
Comment 3 Terrence Cole [:terrence] 2012-04-10 17:05:06 PDT
And backed out in:

Old and busted gcc says: "error: default template arguments may not be used in function templates".
Comment 4 Jeff Walden [:Waldo] (remove +bmo to email) 2012-04-10 17:10:01 PDT
Actually gcc's right about that.  You have to have a pointless <> when calling a templatized function where all the template arguments are defaulted, in C++98.  (C++11 allows you to omit the <> when calling a function using entirely default template arguments.)  Clang should be warning/erroring on the same thing, not sure why it wouldn't be here.

Oh, and it's "invariants", not "invarients".
Comment 5 Jeff Walden [:Waldo] (remove +bmo to email) 2012-04-10 17:11:42 PDT
Er, wait, that first paragraph of comment 4 is not actually correct, or at least I'm not sure it is as regards the situation here -- ignore it.
Comment 6 Terrence Cole [:terrence] 2012-04-11 17:15:38 PDT
Created attachment 614230 [details] [diff] [review]
v1: Carrying review forward, since Luke gave me the working solution. :-)

Using tl::StaticAssert works much better, and is cleaner to boot.
Comment 7 Terrence Cole [:terrence] 2012-04-11 17:17:17 PDT
Comment 8 :Ms2ger (⌚ UTC+1/+2) 2012-04-12 10:22:29 PDT

Note You need to log in before you can comment on or make changes to this bug.