Menu
Search

Forums

Forum Index

September 27, 2021
Gravatar of Steven SchveighofferPosted by Steven Schveighoffer
in reply to Max Samukha		Reply
Steven Schveighoffer
Gravatar of Steven Schveighoffer
Posted in reply to Max Samukha


Reply

On 9/27/21 10:39 AM, Max Samukha wrote:

>

On Monday, 27 September 2021 at 13:59:57 UTC, Steven Schveighoffer wrote:

>

What I'm saying is, if you need a specific address saved for later in a function, wouldn't you prefer to store that on the stack rather than store it in the GC's roots? This would absolutely be opt-in, not automatic, as I don't see how we can do it automatically.

If performance was important, you would want to allocate the object itself on the stack? The cost of GC allocation outweighs that of GC.addRoot by a lot.

That's not as @safe, but it can be a viable option, as long as your object is constructed within your function and not in a factory function.

-Steve

September 27, 2021
Gravatar of jfondrenPosted by jfondren
in reply to Max Samukha		Reply
jfondren
Gravatar of jfondren
Posted in reply to Max Samukha


Reply

On Monday, 27 September 2021 at 14:39:36 UTC, Max Samukha wrote:

>

On Monday, 27 September 2021 at 13:59:57 UTC, Steven Schveighoffer wrote:

>

What I'm saying is, if you need a specific address saved for later in a function, wouldn't you prefer to store that on the stack rather than store it in the GC's roots? This would absolutely be opt-in, not automatic, as I don't see how we can do it automatically.

If performance was important, you would want to allocate the object itself on the stack? The cost of GC allocation outweighs that of GC.addRoot by a lot.

scope makes sense for the examples given but "I want this object to live at least as long as this variable's scope" and "I want this object to die at this end of this scope" are different desires.

September 27, 2021
Gravatar of ElronndPosted by Elronnd
in reply to Max Samukha		Reply
Elronnd
Gravatar of Elronnd
Posted in reply to Max Samukha


Reply
On Monday, 27 September 2021 at 14:39:36 UTC, Max Samukha wrote:
> If performance was important, you would want to allocate the object itself on the stack? The cost of GC allocation outweighs that of GC.addRoot by a lot.

The cost of GC _collection_ outweighs that of GC.addRoot by a lot.  GC _allocation_ is pretty much free.
September 27, 2021
Gravatar of deadalnixPosted by deadalnix
in reply to Steven Schveighoffer		Reply
deadalnix
Gravatar of deadalnix
Posted in reply to Steven Schveighoffer


Reply

On Monday, 27 September 2021 at 13:59:57 UTC, Steven Schveighoffer wrote:

>

What I'm saying is, if you need a specific address saved for later in a function, wouldn't you prefer to store that on the stack rather than store it in the GC's roots? This would absolutely be opt-in, not automatic, as I don't see how we can do it automatically.

-Steve

Honestly, I don't see why storing the GC root needs to be expensive. If it is that is a problem. You could literally compare and swap a counter to get a slot in the buffer and then store the pointer there, and granted there is no contention, it's effectively free (and if you have contention on addRoot, I can tell you what i'm talking about here is the least of your concerns).

September 28, 2021
Gravatar of ElronndPosted by Elronnd
in reply to deadalnix		Reply
Elronnd
Gravatar of Elronnd
Posted in reply to deadalnix


Reply
On Monday, 27 September 2021 at 22:15:26 UTC, deadalnix wrote:
> I don't see why storing the GC root needs to be expensive

Because you need to be able to remove the root later.  So it essentially reduces to a hash table.  Wrt contention, concurrent hash table is doable (https://github.com/boundary/high-scale-lib/blob/master/src/main/java/org/cliffc/high_scale_lib/NonBlockingHashMap.java) but would need to be implemented; however I agree with Steven that I don't understand why you would do this when you could just store the pointer on the stack or in a register.
September 28, 2021
Gravatar of Max SamukhaPosted by Max Samukha
in reply to Elronnd		Reply
Max Samukha
Gravatar of Max Samukha
Posted in reply to Elronnd


Reply
On Monday, 27 September 2021 at 22:10:25 UTC, Elronnd wrote:
> On Monday, 27 September 2021 at 14:39:36 UTC, Max Samukha wrote:
>> If performance was important, you would want to allocate the object itself on the stack? The cost of GC allocation outweighs that of GC.addRoot by a lot.
>
> The cost of GC _collection_ outweighs that of GC.addRoot by a lot.  GC _allocation_ is pretty much free.

Yeah, "by a lot" is nonsense.
September 28, 2021
Gravatar of deadalnixPosted by deadalnix
in reply to Elronnd		Reply
deadalnix
Gravatar of deadalnix
Posted in reply to Elronnd


Reply
On Tuesday, 28 September 2021 at 06:38:20 UTC, Elronnd wrote:
> On Monday, 27 September 2021 at 22:15:26 UTC, deadalnix wrote:
>> I don't see why storing the GC root needs to be expensive
>
> Because you need to be able to remove the root later.  So it essentially reduces to a hash table.  Wrt contention, concurrent hash table is doable (https://github.com/boundary/high-scale-lib/blob/master/src/main/java/org/cliffc/high_scale_lib/NonBlockingHashMap.java) but would need to be implemented; however I agree with Steven that I don't understand why you would do this when you could just store the pointer on the stack or in a register.

Even then, unless you addRoot like mad, linear search through the array is goign to be super fast (in fact, LLVM DenseSet/DenseMap do exactly that untill the element count gets too high).
September 29, 2021
Gravatar of John ColvinPosted by John Colvin
in reply to deadalnix		Reply
John Colvin
Gravatar of John Colvin
Posted in reply to deadalnix


Reply
On Tuesday, 28 September 2021 at 16:22:40 UTC, deadalnix wrote:
> On Tuesday, 28 September 2021 at 06:38:20 UTC, Elronnd wrote:
>> On Monday, 27 September 2021 at 22:15:26 UTC, deadalnix wrote:
>>> [...]
>>
>> Because you need to be able to remove the root later.  So it essentially reduces to a hash table.  Wrt contention, concurrent hash table is doable (https://github.com/boundary/high-scale-lib/blob/master/src/main/java/org/cliffc/high_scale_lib/NonBlockingHashMap.java) but would need to be implemented; however I agree with Steven that I don't understand why you would do this when you could just store the pointer on the stack or in a register.
>
> Even then, unless you addRoot like mad, linear search through the array is goign to be super fast (in fact, LLVM DenseSet/DenseMap do exactly that untill the element count gets too high).

If you search from most recently added to least recent then it’ll be super cheap in most cases. Almost stack-like.
September 29, 2021
Gravatar of ElronndPosted by Elronnd
in reply to John Colvin		Reply
Elronnd
Gravatar of Elronnd
Posted in reply to John Colvin


Reply
On Wednesday, 29 September 2021 at 07:23:26 UTC, John Colvin wrote:
> If you search from most recently added to least recent then it’ll be super cheap in most cases. Almost stack-like.

Yes, but pathological in the worst case.  Kinda like a freelist without compaction, except your worst case isn't bounded.

The generational GC hypothesis is relevant.  It says that the worst case will come up, though it will be the exception rather than the rule; however, I don't know if the sorts of objects that need to be explicitly protected have usual lifetimes, so the situation might be even worse.
September 30, 2021
Gravatar of deadalnixPosted by deadalnix
in reply to Elronnd		Reply
deadalnix
Gravatar of deadalnix
Posted in reply to Elronnd


Reply
On Wednesday, 29 September 2021 at 22:17:25 UTC, Elronnd wrote:
> On Wednesday, 29 September 2021 at 07:23:26 UTC, John Colvin wrote:
>> If you search from most recently added to least recent then it’ll be super cheap in most cases. Almost stack-like.
>
> Yes, but pathological in the worst case.  Kinda like a freelist without compaction, except your worst case isn't bounded.
>
> The generational GC hypothesis is relevant.  It says that the worst case will come up, though it will be the exception rather than the rule; however, I don't know if the sorts of objects that need to be explicitly protected have usual lifetimes, so the situation might be even worse.

You can always fall back to a set when things get large.
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10
Next ›   Last »