743854 - GC: extra barriers in ArrayBuffer::create

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Terrence Cole [:terrence]]

ArrayBuffers have 16 inline slots that the typearray uses to store arbitrary data.  Out of ArrayBuffer::create we end up calling JSObject::create, which calls initializeSlotRange, which calls init() on each of the 16 inline slots.  The post barrier puts a reference to each of these in the write buffer.  The typearray code goes on to write arbitrary data to these slots.  When we GC, we attempt to figure out if these values contain a GCThing and potentially dereference the "pointers" stored there.  These contain garbage: kaboom.

Comment 1

[Terrence Cole [:terrence]]

Attachment: v0

Simple, but ugly.  I'm not sure if it would be worth adding a special class flag for only this one case.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Is there any way we can do this without loading the class from the shape? Most of the callers I see already have the class in a local variable.

Comment 3

[Terrence Cole [:terrence]]

This code already calls shape->getObjectClass()->getPrivate() in the branch immediately above this one.  We should just store that and re-use it.

Comment 4

[Terrence Cole [:terrence]]

Attachment: v1: Keep the Class in a shared local.

Bill, I talked this over with Waldo and sfink this morning. Slotspan is just used differently by ArrayBuffers, so it seems that doing this specialization is the right way to go for now.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Comment on attachment 624446 [details] [diff] [review]
v1: Keep the Class in a shared local.

OK, but please call it clasp.

Comment 6

[Terrence Cole [:terrence]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a8f13db7bff9

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a8f13db7bff9