Skip to content

Commit 0b78f54

Browse files
kvakilNo9
authored andcommitted
Remove support for unboxed doubles
As of the mentioned upstream commit, the hack we use to detect the possibility of unboxed doubles no longer works. Rather than trying to create another hack, simply hardcode it to false. This requires us to also remove support for EOL versions of Node.js which may still have unboxed doubles.
1 parent c1125a2 commit 0b78f54

2 files changed

Lines changed: 4 additions & 12 deletions

File tree

.github/workflows/push.yml

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -16,8 +16,6 @@ jobs:
1616
fail-fast: false
1717
matrix:
1818
node:
19-
- version: 10.x
20-
- version: 12.x
2119
- version: 14.x
2220
- version: 16.x
2321
- version: 18.x

src/llv8-constants.cc

Lines changed: 4 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -139,16 +139,10 @@ void Map::Load() {
139139

140140

141141
bool Map::HasUnboxedDoubleFields() {
142-
// LayoutDescriptor is used by V8 to define which fields are not tagged
143-
// (unboxed). In preparation for pointer compressions, V8 disabled unboxed
144-
// doubles everywhere, which means Map doesn't have a layout_descriptor
145-
// field, but because of how gen-postmortem-metadata works and how Torque
146-
// generates the offsets file, we get a constant for it anyway. In the future
147-
// unboxing will be enabled again, in which case this field will be used.
148-
// Until then, we use the presence of this field as version (if the field is
149-
// present, it's safe to assume we're on V8 8.1+, at least on supported
150-
// release lines).
151-
return !kLayoutDescriptor.Loaded();
142+
// V8 has now disabled unboxed doubles in all supported Node.js branches. Per
143+
// the V8 authors (v8/v8@42409a2e) it seems unlikely this support will ever
144+
// return, so we could probably just remove it entirely.
145+
return false;
152146
}
153147

154148
void JSObject::Load() {

0 commit comments

Comments
 (0)