Open Bug 1549579 Opened 7 years ago Updated 1 year ago

AllocationMetadataBuilder is too general

Categories

(Core :: JavaScript Engine, task, P3)

task

Tracking

()

People

(Reporter: jimb, Unassigned)

References

(Blocks 1 open bug)

Details

Letting an arbitrary AllocationMetadataBuilder drive metadata collection for JS object allocations makes it hard for multiple consumers to request metadata collection simultaneously. Because the virtual base class gives no information about what the implementation actually does, there's no reasonable way to determine the "union" of multiple requests.

For example, both the devtools and the profiler may want allocation metadata (see bug 1545582), but if the two provide distinct AllocationMetadataBuilder instances, there's no way to reconcile them.

The only reason the situation is tenable at the moment is that, in fact, there is only one AllocationMetadataBuilder anyone wants to use, outside of testing code. So there would be no loss in observable functionality if we simply had a single form of metadata that can be collected, and let it be either on or off. This would substantially simplify the plumbing, and free bug 1545582 from inventing unsatisfying answers to questions nobody really cares about.

If different consumers really have different needs, perhaps we could have a bitmask of data to include - but still have a single builder.

Priority: -- → P3
Severity: minor → S4
Blocks: sm-runtime
Severity: S4 → N/A
Type: enhancement → task
You need to log in before you can comment on or make changes to this bug.