Some changes to the GarbageCollection in Island?

Elements Oxygene
, , ,
1

Hi,

recently, I have gone through your island api on github and saw some changes which you have seemingly made on the GC lvl, didnt you?

For interessting issues, what did you change so far and why? Love to know about it, everything about GC i consider cool :wink:

2

We didn’t change the algorithm; however what did happen is that the GC is now pluggable. On WebAssembly there’s a different GC (single threaded, reference counted with cycle support)

3

Ah ok, cool to know then :slight_smile:

Anyhow, I wonder what you are up to in relation to the RAII - Concept of C++ MemoryManagement? What do you think about its model? Love to hear your opinion :wink:

RAII => Resource Aquisition is Initialization

4

We do have some limited RAII support when using records on Island. Essentially:

constructor;
 // gets called when defining a type of that type but not explicitly initializing it.

constructor Copy(var aValue: StructType);
// gets called when create a value from another value (should copy but "self" will be uninitialized).

class operator Assign(var aDest: StructType; var aSource: StructType);
//  gets called for a = b assignments; both aDest and aSource are initialized; if @aDest <> @aSource then aDest should be cleaned up.

finalizer;
// gets called when the scope for that type ends.
1 Like
5

Is it restrivcted with records only, or how do you mean it is “limited” ?

6

It makes no sense in the concept of classes since those are GC managed.

It’s limited in that it doesn’t support all of the c++ raii operations, but can probably accomplish anything you want anyway.

7

Ah yes :slight_smile:

am I then able to manipulate something consiously, or is this done automatically by the compiler?

8

I have no idea what you are asking.

9

so when using records, do I have something to do, for instance, using some raii-operators explicitly or is it autom cleaned up after each function, so when a record keeps unmanaged resources, because C++ uses mangement-classes for this, to wrap the unmanaged-resources and calling the destructor of the class when the lifetime of the function ends, so the handle(ptr) ends aswell, as without being wrapped in a class, hopefully u understand me ^^

10

Because this ofc makes only sense by unmanaged-resources as valuetypes are destroyed after they go out of scope, so I thought we should use records to encapsulate the pointerstuff and then let the stack do both, remove the record from stack and clean up unmang. resources

11

Right; structs are cleaned up deterministically.

12

Ok, can you tell me, how shall I use this concept of RAII in Oxygene-island now?

How to work with this model properly?

13

The better question is: What are you trying to accomplish? As I said, when using records you can get full control over the lifetime of the type.

14

Actually, I just have been really interessted in proper memory-management, so it was just a general issue for me, no concrete thing.

And what do you thing about this, is it not a good practice or yes or what?

TMutex = public record
  someStuff: TStuff;
  //and so on...
end;

TLock = public record
private
  mutexProp: ^TMutex;
public
  constructor(pm: ^TMutex);
  begin
     mutexProp := pm;
     Mutex_Lock(mutexProp);
  end;

finalizer();
begin
  Mutex_Unlock(mutexProp);
end;
end;

So, when using in a function, u now use the TLock-record instead of just the functions from “Mutex_Lock(pm) - Mutex_Unlock(pm)” because the mutex could be always locked, in case of some error occurs before unlocking the mutex.

15

That will work yes and will call the finalizer at the end of the scope (the begin/end it’s contained in)

16

So for such cases, i.e, shall I use better records, because it could be a problem with the GC, as it is not known when he starts collecting/finalizing

17

Right, with the gc you’d use a try/finally or using to require this. Structs are a better solution in this case.

1 Like