On heap segregation, GC optimization and @nogc relaxing

deadalnix via Digitalmars-d digitalmars-d at puremagic.com
Wed Nov 12 13:27:59 PST 2014


On Wednesday, 12 November 2014 at 20:36:32 UTC, Dmitry Olshansky 
wrote:
> Seems sane. owned(Exception) would be implicitly assumed i.e.:
> catch(Exception e){ ... }
>
> would be seen by compiler as:
> catch(owned(Exception) e){ ... }
>
> What happens if I throw l-value exception? Do I need to cast or 
> assumeOwned it?
>
> It's easy to see how it goes with r-values, such as new 
> Exception(...), since they are "unique expressions" whatever 
> that means ;)
>

Yes, the unsafe road must always be open, we are a system 
programming language :)

> I take it that owned(T) is implicitly deduced by compiler in 
> case of pure functions? Also it seem templates should not take 
> owned(T) into consideration and let it decay... How does owned 
> compose with other qualifiers?
>

You mean what is I have an owned field into an object ? In the 
case you pass the owned where a TL, shared or immutable is 
expected, the island is merged so the question do not make sense.

An owned field in an object is interpreted as follow:
  - immutable => immutable
  - shared => owned (and can be touched only if the shared object 
is synchronized, which allow to hide a whole hierarchy behind a 
mutex. That is another selling point but I don't wanted to get 
into all the details as the post was already quite big).
  - const => const owned (essentially unusable - except via 
burrowing if we ever want to go that road one day).

> Seems absolutely cool. But doesn't allocating exception touches 
> heap anyway? I take it that if I don't save exception 
> explicitly anywhere the owned island is destroyed at catch 
> scope?
>

Yes it touches the heap. But as long as things are owned, they'll 
be freed automatically when going out of scope. That means, with 
that definition of things, what is forbidden in @nogc code is to 
consume the owned in such a fashion that its island is merged 
into TL, shared or immutable heap. If you don't do this, then 
your isolated will be freed when going out of scope and the GC 
won't need to kick in/no garbage will be produced.

Doing so allow for relaxing the constraint in @nogc and allow for 
the same library code to be used with or without GC.


More information about the Digitalmars-d mailing list