On 9/23/21 3:40 PM, H. S. Teoh wrote:

You can. But wouldn't you prefer just pushing something on the stack?

I don't know, it sort of bugs me and fascinates me that there isn't a way to do this easily. The stack is pretty much free to use, adding something to some allocated tree inside the GC (and then later removing it) isn't.

The use cases are exceedingly small though...

-Steve

On Thursday, 23 September 2021 at 19:54:56 UTC, Steven Schveighoffer wrote:

I would expect this to work on all platforms and compilers...
scope c = new C;

On 9/23/21 4:43 PM, Daniel N wrote:

This isn't quite the same. This puts c's guts on the stack, which is much less @safe than just putting a reference on the stack.

-Steve

On Thursday, 23 September 2021 at 19:54:56 UTC, Steven Schveighoffer wrote:

It doesn't matter where it is, stack or register. What is important is that the pointer value is retained somewhere. KeepAlive should trick the compiler to believe that KeepAlive itself is a user of the resource. How that is done in practice is another question and may vary depending on GC type.

On Tuesday, 21 September 2021 at 12:02:05 UTC, Steven Schveighoffer wrote:

struct Pin(T)
{
   T t;
   @nogc nothrow pure @safe ~this() {}
   alias t this;
}

...
// usage
auto c = Pin!C(new C); // now it needs to be held until the scope ends

Another way:

struct Pin(T)
{
   T t;
   ~this()
   {
      import core.volatile;
      volatileLoad(cast(uint*)&t);
   }
}

// usage
auto c = Pin!C(new C);

On 9/23/21 5:34 PM, IGotD- wrote:

Right, the registers are scanned too. In fact, I'm pretty sure when looking at the code LDC generates when using my latest keepalive lib, it can use a non-temporary register to store the pointer, and then when it comes time to call the destructor, it puts the pointer on the stack (because destructors require a pointer).

And a register is even more performant than the stack!

-Steve

On 9/23/21 3:29 PM, Paulo Pinto wrote:

Yes, I took a lot of inspiration from that.

auto c = new C;
// ... lots of ongoing activities ...
keepAlive(c); // c will survive until keepAlive returns.

Right, what I'd prefer is something that doesn't actually require a call or code of any kind, but the empty asm seems to require the minimum.

Note that using my keepalive library that way (just calling c.keepAlive at the end of the function) will also work.

-Steve

On Thursday, 23 September 2021 at 19:54:56 UTC, Steven Schveighoffer wrote:

Not really. If the optimizer can remove dead stack pushes, then program will become 2x slower instantly in addition of consuming more stack memory.

On Friday, 24 September 2021 at 15:25:55 UTC, deadalnix wrote:

Doubt it would be 2x on a modern CPU. Point stands though. LLVM and GCC both have intrinsics for GC roots so perhaps they could be used here (calling into the GC is going to be very slow anyway so keeping it's return value on the stack wouldn't matter)

On 9/24/21 11:25 AM, deadalnix wrote:

You think pushing on the stack is going be 2x slower than calling GC.addRoot?

-Steve