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.
Created attachment 613440 [details] [diff] [review] v0 Simple, but ugly. I'm not sure if it would be worth adding a special class flag for only this one case.
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.
This code already calls shape->getObjectClass()->getPrivate() in the branch immediately above this one. We should just store that and re-use it.
Created attachment 624446 [details] [diff] [review] 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 on attachment 624446 [details] [diff] [review] v1: Keep the Class in a shared local. OK, but please call it clasp.