1503759 - Revisit how Spidermonkey handles variable length structs

Status: NEW

(Core :: JavaScript Engine, enhancement, P3)

Description

[Ted Campbell [:tcampbell]]

In SpiderMonkey we like to allocate structs and then have trailing arrays after them. Each time we seem to take a different approach (usually historical artifacts) and generally are taking a stroll through the woods of C++ Undefined Behavior.

I'd be interested in the idea of using LLVM TrailingObjects (http://llvm.org/doxygen/TrailingObjects_8h_source.html) or something similar.

On top of reducing existing undefined behavior, I think a consistent system would make it easier to add/move/remove various arrays all over the VM which is useful as we evolve the engine.

Current variable-length data structures in js/src:
 - js::ArgumentsData
 - js::DebugScript
 - js::NativeIterator
 - js::PrivateScriptData
 - js::RareArgumentsData
 - js::SharedScriptData
 - js::TrailingNamesArray
 - js::TypeScript
 - js::detail::ProxyValueArray
 - js::jit::BaselineScript
 - js::jit::IonScript
 - js::jit::IonTrackedOptimizationsOffsetsTable
 - js::jit::JitcodeGlobalEntry::IonEntry::SizedScriptList
 - js::jit::JitcodeIonTable
 - js::jit::JitcodeSkiplistTower
 - js::jit::RematerializedFrame
 - (more?)

Some of these try their best to be good C++ citizens and others are more questionable. I think having a standard approach for as many as possible is a win in maintainability of engine.

Seeking ideas on how to address. I think the bespoke implementations many of these classes use are not gaining us much and I'd be interested in what a TrailingObjects experiment would look like.

Comment 1

[Jan de Mooij [:jandem]]

Yes please. These are a pain to write manually.