A picture is worth a thousand words, they say.
Where I left off yesterday, I was trying to figure out why my generated AddRecordProperty code was crashing. I was still using the simplest possible test case, a record with one field:
function f() { x = #{"a": 1}; }
Fixed slots
My code was writing a literal zero into the record’s “initialized length” slot:
store32(Imm32(0), Address(result, NativeObject::getFixedSlotOffset(RecordType::INITIALIZED_LENGTH_SLOT)));
But this should have been:
storeValue(Int32Value(0), Address(result, NativeObject::getFixedSlotOffset(RecordType::INITIALIZED_LENGTH_SLOT)));
In the drawing, I indicated that offset 24 of a RecordType is a Value (JS::Value) denoting the number of elements that have been initialized so far. While it’s an invariant that this will actually be an integer value, as far as the compiler is concerned, the representation is of a Value, which has a different bit pattern from the integer 0.
Some existing code in RecordType::createUninitializedRecord() (this is code that isn’t upstream yet) should have been a clue:
uint32_t length = getFixedSlot(INITIALIZED_LENGTH_SLOT).toPrivateUint32();
To get an unsigned int32, we call the Value method toPrivateUint32(), which returns an integer when called on an integer value.
Moreover, the getFixedSlot() method of NativeObject also returns a Value, which should have been a pretty good hint to me that fixed slots are Values:
const Value& getFixedSlot(uint32_t slot) const;
Observing the length field
Supposing that the register %rcx points to a record, I would like to be able to execute:
call js::DumpValue(((RecordType*) $rcx)->getFixedSlot(INITIALIZED_LENGTH_SLOT))
in gdb. (Where INITIALIZED_LENGTH_SLOT is defined as 0, since it happens to be the first fixed slot in this object.) Casting the value in %rcx to RecordType is necessary to tell gdb where the struct fields begin and end, but from there, I would have thought there would be enough debug information for it to know that RecordType inherits from NativeObject, which has a getFixedSlot() method.
Since I can’t do that, the next best thing is:
(gdb) call js::DumpValue( (JS::Value::fromRawBits (*($rcx + 24)) )) 0
And that works — it prints 0, which is what I would expect for a record with no initialized fields. Effectively, I inlined getFixedSlot(), which accesses offset 24 from the object. Then, JS::Value::fromRawBits decodes the tagged pointer that represents a Value, and DumpValue() pretty-prints it.
Observing the sortedKeys field
Looking at the picture again, records have a second fixed slot that’s a Value that is guaranteed (assuming the compiler works) to correspond to an ArrayObject, which just contains the record keys, in sorted order. I knew that my code was temporarily storing the value of this slot in register %rbx (as before, I figured this out by putting breakpoints in the code generation methods and looking at the values of various variables), so if I do:
call js::DumpValue ((JS::Value::fromRawBits($rbx)))
in gdb, I get output that’s something like <Array object at 232d468007f8>
But for more detail, I can do:
(gdb) call js::DumpObject (& ((JS::Value::fromRawBits($rbx)).toObject()))
object 29574ae007f0
global 21bd66c40030 [global]
class 5555590a8770 Array
shape 21bd66c66320
flags:
proto
properties:
[Latin 1]"length" (map 21bd66c62670/0 writable )
which interprets the Value as an Object and uses DumpObject to print out more details about its representation.
Observing the record itself
Having seen that the individual fixed slots of the record seemed to be correct, I wanted to debug my generated code for creating uninitialized records to see what the entire record object looked like. Knowing that the record was stored in %rcx, I figured out that I could do:
(gdb) call js::DumpObject (& ((JS::Value::fromRawBits($rcx)).toExtendedPrimitive()))
object 29574ae007b0
global 21bd66c40030 [global]
class 5555590b7d10 record
shape 21bd66c663c0
flags:
proto null
reserved slots:
0 : 0
1 :
2 : false
properties:
elements:
0: false
1: Assertion failure: (asBits_ & js::gc::CellAlignMask) == 0 (GC pointer is not aligned. Is this memory corruption?), at /home/tjc/gecko-fork/obj-x64-debug/dist/include/js/Value.h:622
“Extended primitive” is a provisional name for records and tuples, which are not objects, but are (in our prototype implementation) represented internally in the compiler as objects; that’s why I’m able to use DumpObject to print out the fields. Under “reserved slots”, it’s showing me the values of the three reserved slots shown at offsets, 24, 32, and 40 in the picture above.
Obviously, it’s a warning sign that trying to print out the elements array causes an assertion failure. I would like to be able to print it out using:
call js::DumpValue(((RecordType*) $rcx)->getElements()[0])
since getElements() is a NativeObject method that represents an array of Values. But this doesn’t work in gdb, so knowing that the offset of the elements_ field is 16, I did the following:
(gdb) p *(ObjectElements::fromElements((HeapSlot*) ($rcx + 16)))
$10 = { flags = 3952501696, initializedLength = 13525, capacity = 1437286072, length = 21845}
(gdb)
I deleted some of the output so as to show only the dynamic fields. The picture above makes this much clearer, but once we access the HeapSlot array stored in the elements_ field, we can call the ObjectElements::fromElements method on it to access the elements header, which is stored physically before the array itself. This header consists of four int32 fields: flags, initializedLength, capacity, and length. This output makes it seem like garbage got written into the object, since the initialized length shouldn’t be 13525.
Looking at the slots_ array of the record (which is at offset 8), I observed:
p ((HeapSlot*) (*($rcx + 8))) $22 = (js::HeapSlot *) 0x55ab3eb8 (gdb)
This coresponds to this MacroAssembler call:
storePtr(ImmPtr(emptyObjectSlots), Address(result, NativeObject::offsetOfSlots()));
result here represents the register that contains the record, and offsetOfSlots() is 8. I had copied/pasted this code from existing code that initializes arrays, without looking at it too carefully, but when I read it again, I noticed that emptyObjectSlots is a special value. A comment in NativeObject.h mentions that special singleton values are used when the elements_ and slots_ arrays are empty.
Initializing the elements
And that’s how I realized that some other code that I had copied and pasted out of the existing array initialization code was misplaced:
// Initialize elements pointer for fixed (inline) elements.
computeEffectiveAddress(
Address(result, NativeObject::offsetOfFixedElements()), temp);
storePtr(temp, Address(result, NativeObject::offsetOfElements()));
This works fine for what it does, but I needed to do the equivalent of the NativeObject::setEmptyElements() method:
Should do exactly what NativeObject::setEmptyElements() does:
void setEmptyElements() { elements_ = emptyObjectElements; }
(code)
So what I really wanted was:
// Initialize elements pointer
storePtr(ImmPtr(emptyObjectElements),
Address(result, NativeObject::offsetOfElements()));
And after making that change, the elements header looked a lot better:
(gdb) p (*((ObjectElements*) ($rcx)))
$8 = {flags = 0, initializedLength = 0, capacity = 1, length = 1, static VALUES_PER_HEADER = 2}
(gdb) call ((JSObject*) $rcx)->dump()
object 17d67b3007b0
global 2689ff340030 [global]
class 5555590b7b80 record
shape 2689ff3663c0
flags:
proto null
reserved slots:
0 : 0
1 :
2 : false
properties:
(gdb)
There’s more to recount, but I don’t have any more time today.
Tags: daily, record-tuple