On Tuesday, 16 June 2015 at 22:21:28 UTC, Steven Schveighoffer wrote:
> If you want to manage memory from a GC'd object, you can use C malloc and C free.
>
> Or, you can write your own GC that solves this problem that Sun/Oracle couldn't :)
>
> In all seriousness, you could potentially have exceptions to this rule, but it would take a lot of cajoling of druntime and some funky @UDA magic.
>
> -Steve

Yeah, I'm going to make a personal branch and develop a GC thread-local, and ensure memory/vtbl is left intact during collection/finalization, it's a good experiment and I believe it will be a way to solve the issue in the near future. Of course, no support for moving shared objects in a foreign thread anymore.. like that was any useful in the first place :P

On Tuesday, 16 June 2015 at 22:31:38 UTC, Etienne Cimon wrote:
> Yeah, I'm going to make a personal branch and develop a GC thread-local, and ensure memory/vtbl is left intact during collection/finalization, it's a good experiment and I believe it will be a way to solve the issue in the near future. Of course, no support for moving shared objects in a foreign thread anymore.. like that was any useful in the first place :P

My libraries run fine on a TLS GC so far:

https://github.com/etcimon/druntime/commit/7da3939637bd1642400dbed83e3b0ff2844386ac

Only error was with a signal handler trying to allocate on the GC. I think it'll be worth it for me to use this from now on. There's no locking and possibly no stop the world.

On Tue, 16 Jun 2015 16:28:53 +0000, Etienne wrote:

> To be fair, everything is bug prone until you understand them. GC finalization is done in a single lock, none of the memory is re-used, so objects can have their own "destroyed" flags and destroy eachother fine if the typeinfo issue isn't there.

this is an implementation detail. nothing guarantees that is will stay like that even for one more commit. relying on this means that your code is bugged and can break at any time, without warning. more than that, if user pulled in another GC implementation, completely adhering to specs, your code simply goes nuts, forcing the poor user to guess what's wrong.

so as other people already wrote, simply "don't do it". there will be no way to do what you want here until GC requirements in specs will be changed (and this is unlikely to happen).

On Wed, 17 Jun 2015 02:35:39 +0000, Etienne Cimon wrote:

> Only error was with a signal handler trying to allocate on the GC.

signal handlers shouldn't allocate at all, being that from GC, or from libc, or from some other allocator. the only thing signal handler can do safely is setting some flag. anything other is working by pure luck.

On Wednesday, 17 June 2015 at 14:19:33 UTC, ketmar wrote:
> this is an implementation detail. nothing guarantees that is will stay like that even for one more commit. relying on this means that your code is bugged and can break at any time, without warning. more than that, if user pulled in another GC implementation, completely adhering to specs, your code simply goes nuts, forcing the poor user to guess what's wrong.
>
> so as other people already wrote, simply "don't do it". there will be no way to do what you want here until GC requirements in specs will be changed (and this is unlikely to happen).

If we can freeze the druntime interface anytime soon (while adding said support to the interface), the library can be subject to micro-optimizations by deferring the linking process and allowing it to be compiled and linked through dub.

This allows applications to use whatever GC is best for them. Parallel, precise, thread-local, you name it.

This being said, I know my use of the core.gc implementation carries no forward guarantees, so, I might end up dragging it along for a while and merging only certain parts of druntime in the future.

On Wed, 17 Jun 2015 14:47:12 +0000, Etienne Cimon wrote:

> This being said, I know my use of the core.gc implementation carries no forward guarantees, so, I might end up dragging it along for a while and merging only certain parts of druntime in the future.

sure, you can do that; i'm doing a similar thing with my Aliced. but the price is that people with "vanilla" implementation can't use your code anymore. ah, and sometimes you're forgetting about some prerequisites, and your code stops working too. ;-)

On Wednesday, 17 June 2015 at 02:35:40 UTC, Etienne Cimon wrote:
> On Tuesday, 16 June 2015 at 22:31:38 UTC, Etienne Cimon wrote:
>> Yeah, I'm going to make a personal branch and develop a GC thread-local, and ensure memory/vtbl is left intact during collection/finalization, it's a good experiment and I believe it will be a way to solve the issue in the near future. Of course, no support for moving shared objects in a foreign thread anymore.. like that was any useful in the first place :P
>
> My libraries run fine on a TLS GC so far:
>
> https://github.com/etcimon/druntime/commit/7da3939637bd1642400dbed83e3b0ff2844386ac
>
> Only error was with a signal handler trying to allocate on the GC. I think it'll be worth it for me to use this from now on. There's no locking and possibly no stop the world.

why 'possibly' ?

On Wednesday, 17 June 2015 at 18:41:13 UTC, Laeeth Isharc wrote:
> On Wednesday, 17 June 2015 at 02:35:40 UTC, Etienne Cimon wrote:
>> On Tuesday, 16 June 2015 at 22:31:38 UTC, Etienne Cimon wrote:
>>> Yeah, I'm going to make a personal branch and develop a GC thread-local, and ensure memory/vtbl is left intact during collection/finalization, it's a good experiment and I believe it will be a way to solve the issue in the near future. Of course, no support for moving shared objects in a foreign thread anymore.. like that was any useful in the first place :P
>>
>> My libraries run fine on a TLS GC so far:
>>
>> https://github.com/etcimon/druntime/commit/7da3939637bd1642400dbed83e3b0ff2844386ac
>>
>> Only error was with a signal handler trying to allocate on the GC. I think it'll be worth it for me to use this from now on. There's no locking and possibly no stop the world.
>
> why 'possibly' ?

I hadn't tested it when I wrote that message. I committed the changes today and my tests were successful in a thread-local GC, however I'm still scanning the other thread contexts. The only limitation is that you can't move objects between threads, a pointer must remain in the thread that created it if the object is used in another thread.

https://github.com/etcimon/druntime/commit/78a2bca1356e0514c516e5261649ca0bf686b4cb

On Wednesday, 17 June 2015 at 19:52:41 UTC, Etienne wrote:
https://github.com/etcimon/druntime/commit/7da3939637bd1642400dbed83e3b0ff2844386ac
>>>
>>> Only error was with a signal handler trying to allocate on the GC. I think it'll be worth it for me to use this from now on. There's no locking and possibly no stop the world.
>>
>> why 'possibly' ?
>
> I hadn't tested it when I wrote that message. I committed the changes today and my tests were successful in a thread-local GC, however I'm still scanning the other thread contexts. The only limitation is that you can't move objects between threads, a pointer must remain in the thread that created it if the object is used in another thread.
>
> > https://github.com/etcimon/druntime/commit/78a2bca1356e0514c516e5261649ca0bf686b4cb

I am no compiler/runtime guru, but it sounds like if it were possible to make this a swappable option for D this might be very important.  Is this true, and how much work is involved in making this industrial strength?

On Wednesday, 17 June 2015 at 20:19:45 UTC, Laeeth Isharc wrote:
> On Wednesday, 17 June 2015 at 19:52:41 UTC, Etienne wrote:
> https://github.com/etcimon/druntime/commit/7da3939637bd1642400dbed83e3b0ff2844386ac
>>>> [...]
>>>
>>> why 'possibly' ?
>>
>> I hadn't tested it when I wrote that message. I committed the changes today and my tests were successful in a thread-local GC, however I'm still scanning the other thread contexts. The only limitation is that you can't move objects between threads, a pointer must remain in the thread that created it if the object is used in another thread.
>>
>> > https://github.com/etcimon/druntime/commit/78a2bca1356e0514c516e5261649ca0bf686b4cb
>
> I am no compiler/runtime guru, but it sounds like if it were possible to make this a swappable option for D this might be very important.  Is this true, and how much work is involved in making this industrial strength?

that it falls apart as soon as you introduce any form of non-message passing threading and/or global variables?
if it was this easy, it would be done already.