[toddh]

> Can passivation warmth be controlled?

A variant of the cold start problem. How long after all the messages for an object drain is it passivated? Can you keep it pinned in memory?

Another question. Can objects contain relationships that are themselves references to other Durable Objects? Say a simple reference, or a list, or DAGs?

[kentonv]

The system will evict the live object when it has been idle for some period. If there are connections still open to the object, it won't be evicted (unless it exceeds resource limits, etc.).

As always, "cold starts" with Workers are very fast, usually imperceptible to a human. Also, multiple objects may be hosted in the same isolate; when instantiating in an existing isolate, the only "cold start" overhead is whatever you write in your class constructor.

> Can objects contain relationships that are themselves references to other Durable Objects?

Yes, by storing the object IDs.

[toddh]

Are they garbage collected? Do you use tombstones?

[kentonv]

No, no GC, at least at present. If you store any durable state, you have to delete it explicitly, or it stays forever.

I am interested in the idea of objects whose IDs are never revealed to the app, but to which references can be stored inside other objects. Then we could do GC... and it would be a true capability system.