Promoting unique boxes to shared boxes

[brson]

I've noticed some issues being filed about the difficulty of creating shared vectors and strings. This could be solved if you could just cast unique boxes to shared boxes, and there aren't many technical obstacles to that.

We are already expecting, for GC purposes, to add some unique boxes to a task-local linked list, similarly to shared boxes. Promoting a unique box to a shared box would simply add it to that list so that the GC or whatever else can find it. The shared memory deallocator would also need to peek at the box header to figure out which allocator it actually came from.

[bblum]

it does not seem too hard to do this with a couple of runtime-representation-aware functions... or maybe even without being aware of the runtime representation.

if #3224 is fixed, it could be implemented with safe code for non-vector cases.

[nikomatsakis]

I've been both excited by this idea and wary of it for a while. I kind of like the firm distinction between unique and shared, but at the same time, it'd be very cool to be able to start something off as ~T and then 'set it free' later on. It would be particularly nice for things like DVec.

[nikomatsakis]

But I do fear that sometime in the future we will regret not knowing whether a ~5 will stay unique or whether it will later become @5.

[Dretch]

Would it be possible to promote borrowed pointers that happened to come from shared boxes back to shared boxes (allocating a new box otherwise)? I realize probably not, but it would be nice...

[bblum]

@Dretch Notionally not -- borrowed pointers are the "supertype" in terms of promotion. You could copy the data into a new box though.

[bblum]

If we did #3472, then promoting an ~ to an @ would have to copy the data over to the @-heap. (You wouldn't want to use the wrong free function; and even if you dynamically decide which one to use, it would still give unpredictable performance.)

[jruderman]

What kind of unpredictable performance? Worse than the cost of copying and the unpredictability of GC pauses?

[brson]

I don't think it would require a copy. The free function can figure out which heap it's really on by walking the linked list of unique allocations that we expect to require for the GC.

[bblum]

yeah, but I mean, if you write code to use @-boxes, it would be nice to know that dropping the last reference is guaranteed not to hit a global lock. if we allow that sort of in-place promotion and dynamic-freeing, it would be much harder to estimate performance.

i'd rather say that promoting has to copy than place the "what is this doing" burden on users of @-boxes everywhere.

[brson]

I think that is overestimating the impact of malloc's locking. The modern thread-aware mallocs are very optimized.

[brson]

But I concede that, in some extreme use cases, one might care that they are hitting jemalloc instead of a hypothetical task-local arena.

[bblum]

I confess to not knowing the intricacies of modern mallocs (though I stand by my "screw over the more unusual use-case" philosophy).

[pcwalton]

I don't think this is a backwards compatibility issue. Renominating.

[graydon]

accepted for feature-complete milestone

[thestinger]

This is currently impossible due to exchange allocations lacking box headers, so I'm just going to close it for the near future.

The garbage collector needs to treat managed-unique pointers as roots and will allocate them on the managed heap. The distinction between the types has to be at compile-time to avoid overhead in exchange allocations, so I think there are barriers to ever implementing this without adding the overhead of tracking it to the GC metadata.