GameMonkey Script

GameMonkey Script Forums
It is currently Mon Nov 20, 2017 3:31 pm

All times are UTC




Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: WriteBarrier
PostPosted: Tue Aug 03, 2010 3:01 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 698
Bock wrote:
Sorry to ressurect an old thread.
Can you clarify if the write barrier has to be applied :
- when moving a reference inside a container? (the gmVariable change location)
- a reference is duplicate (the gmVariable is copied in another place in the container)
etc?
Thanks. :)

I expect the write barrier should be applied in both those cases. You are not showing implementation, but whenever a left-hand-side exists in an assignment, the barrier must be applied. I expect Move, Duplicate and Remove operations would all have this, Add may not if it did not overwrite something. Note that while overuse of the barrier is just inefficient, under-use will cause critical instability.


Top
 Profile  
Reply with quote  
 Post subject: Re: WriteBarrier
PostPosted: Tue Aug 03, 2010 5:20 am 
Offline

Joined: Tue Nov 11, 2008 9:03 am
Posts: 20
Greg wrote:
Bock wrote:
Sorry to ressurect an old thread.
Can you clarify if the write barrier has to be applied :
- when moving a reference inside a container? (the gmVariable change location)
- a reference is duplicate (the gmVariable is copied in another place in the container)
etc?

I expect the write barrier should be applied in both those cases. You are not showing implementation, but whenever a left-hand-side exists in an assignment, the barrier must be applied. I expect Move, Duplicate and Remove operations would all have this, Add may not if it did not overwrite something. Note that while overuse of the barrier is just inefficient, under-use will cause critical instability.

Thanks. Efficiency is a huge concern for us now so I hoped to understand clearly what was necessary and what not.
Why would Duplicate needs it, if its only adding new references?
Maybe to take a simpler example, would a Swap of two elements in a container requires it? (as in, the two references interchange their storage locations)


Top
 Profile  
Reply with quote  
 Post subject: Re: WriteBarrier
PostPosted: Tue Aug 03, 2010 11:13 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 698
Bock wrote:
Why would Duplicate needs it, if its only adding new references?
Maybe to take a simpler example, would a Swap of two elements in a container requires it? (as in, the two references interchange their storage locations)

It is quite possible Duplicate might not need the barrier.
It might be worth re-reading my post, a few post back, dated 22 Jan 2006 as I think it explains the GC write barrier fairly well.
It seems you've got most of it under control.

Summary:
1. GC and write barrier only applies to Objects, not variables, so reference types (as you already note).
2. Objects are referenced by variables, so all operations and storage is usually variable based (unless manually handling things eg. gmGCRoot).
3. The Write Barrier is called to mark objects during assignment. Assignments logically look like A = B.
4. In GMs GC implementation, we only care about the Left Hand Side, so 'A' in this case.

So if A = null, we must WriteBarrier(A) before the assignment, if A = Something, same.
Any time an old variable which contains a reference is overwritten, we must mark it with the write barrier.
Have a look at the existing uses of the write barrier to observe usage.

The logic behind the write barrier is a bit like 'mark it dirty' so it will be reconsidered. Newly allocated objects are already marked in a special way so they will not be GCed for another cycle, that is why this particular implementation does not care about new or newly added objects. The incremental scan implementation processes objects in a pattern so the Right Hand Side or newly copied objects will be scanned without the need for the write barrier. Different implementations require a Write or Read barrier considering the Left, Right or both sides of assignment or access. This implementation is fast and simple but does tend to be conservative, using a bit more memory than aggressive or multi-generational implementations would.


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 03, 2010 1:27 pm 
Offline

Joined: Fri Jan 14, 2005 2:28 am
Posts: 439
Why don't the assignment operators/setters/etc of gmVariable do most of the barrier stuff for you in the situations where it is needed?


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 03, 2010 10:47 pm 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 698
DrEvil-OB wrote:
Why don't the assignment operators/setters/etc of gmVariable do most of the barrier stuff for you in the situations where it is needed?
I suppose they could DrEvil. It would likely add the overhead of a condition per assignment whereas the need for the write barrier is very infrequent. (The more common GC interaction is to temporarily turn off GC during a bound function which plays with objects.) The gmVariable, being the most primitive script type was designed for light weight, people have often added constructors and various checks and extensions to it. It is not a bad idea though and it would be interesting to profile the difference between automatic and manual on a couple of platforms.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group