GC: More barriers on object internals

RESOLVED FIXED in mozilla12

Status

()

Core
JavaScript Engine
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: terrence, Assigned: terrence)

Tracking

Trunk
mozilla12
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

5 years ago
Created attachment 582396 [details] [diff] [review]
v1: barriers on slots and elements.

This adds an "after(.*)RangeOverwritten" to match the existing "prepare(.*)RangeForOverwrite" methods and adds calls to them where needed in the object implementation to properly trigger post-write barriers.  Ironically, this undoes the changes to copyDenseArrayElements I made yesterday: this is a more general solution, applicable in more places (and probably faster as well).

This also removes the void* parameter to HeapValue::writeBarrierPost.  Unlike with the HeapPtr, HeapValue needs to know that addr has Value* type in order to deref it safely.  Because of this, we can't use the addr parameter in HeapValue::writeBarrierPost.  I added it to this patch because this is the first place we use the function directly and not through operator=.
Attachment #582396 - Flags: review?(wmccloskey)
(Assignee)

Updated

5 years ago
Attachment #582396 - Flags: review?(wmccloskey)
(Assignee)

Comment 1

5 years ago
Created attachment 583027 [details] [diff] [review]
v2: Uses loops everywhere.

This is quite a bit clearer.
Attachment #582396 - Attachment is obsolete: true
Attachment #583027 - Flags: review?(wmccloskey)
Comment on attachment 583027 [details] [diff] [review]
v2: Uses loops everywhere.

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

::: js/src/jsobj.cpp
@@ +4509,5 @@
>                                           ps, fs, static_ps, static_fs, ctorp, ctorKind);
>  }
>  
>  void
> +JSObject::initSlotRange(size_t start, const Value *vector, size_t length)

How about adding a getSlotRange method? It would use the current branching logic to generate four things:
  fixedStart, fixedEnd, slotsStart, slotsEnd
These would be returned as HeapValue** parameters.

Then the code for initSlotRange would be:
  getSlotRange(&fixedStart, &fixedEnd, &slotsStart, &slotsEnd);
  for (HeapValue *vp = fixedStart; vp != fixedEnd; vp++)
    vp->init(comp, *vector++);
  for (HeapValue *vp = slotsStart; vp != slotsEnd; vp++)
    vp->init(comp, *vector++);

And the code for copySlotRange would be similar, except that it would use set instead of init.

::: js/src/jsobj.h
@@ +702,5 @@
>      inline void prepareElementRangeForOverwrite(size_t start, size_t end);
>  
>      /*
> +     * Initialize a flat array of slots to this object at a start slot.  The
> +     * caller must ensure that are enough slots.

Let's rewrite this. How about:
"Initialize the slots in the range [start, start+length) to values from vector. The caller must ensure that there are enough slots."
Attachment #583027 - Flags: review?(wmccloskey) → review+
(Assignee)

Comment 3

5 years ago
Created attachment 584639 [details] [diff] [review]
v3: With review feedback.

For posterity, since there was a bit of reworking needed.
Attachment #583027 - Attachment is obsolete: true
Attachment #584639 - Flags: review+
(Assignee)

Comment 4

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/09f21c144fe9
https://hg.mozilla.org/mozilla-central/rev/09f21c144fe9
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
You need to log in before you can comment on or make changes to this bug.