On heap segregation, GC optimization and @nogc relaxing

[Dmitry Olshansky via Digitalmars-d]

13-Nov-2014 00:27, deadalnix пишет:
> 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.

Sorry, forgot to reply.

Here is the case I wanted to check:

try{
	...
}
catch(owned(Exception) e){
	foo(e);
}

void foo(T)(T arg){
	// what would this print? Exception or owned(Exception)
	// do we bloat a bit more on qualifiers?
	pragma(msg, T);
}


>
> 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).
>

Thanks, looks sane.

>> 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.


-- 
Dmitry Olshansky