On 6/17/20 5:06 AM, Jacob Carlborg wrote:
> On 2020-06-17 06:08, H. S. Teoh wrote:
> 
>> As of recent releases, GC initialization is actually lazy now, it will
>> not initialize anything until you actually use it.  Still one step away
>> from being totally optional, granted, but it shouldn't be *too*
>> difficult to make it so that, e.g., the GC code isn't even linked unless
>> there's a reference to one of its symbols somewhere.
> 
> How would the GC know if it needs to initialize itself if you allocate the object at compile time, i.e.:
> 
> __gshared a = new Object; // module scope

Wouldn't that be allocated during compilation, and frozen at runtime (i.e. essentially static data)? That's my recollection of what happens.

> Or is it expected that the above object fill never be freed?

I don't think it's ever allocated actually.

On Wednesday, 17 June 2020 at 12:48:03 UTC, Andrei Alexandrescu wrote:
> Wouldn't that be allocated during compilation, and frozen at runtime (i.e. essentially static data)?

Yeah. You can modify the object (it is not const), but its memory address is statically allocated and will never change / be freed, even if you overwrite all the references. It is part of the exe file.

(this fact is actually useful for many things but it can be confusing)

On Wednesday, 17 June 2020 at 10:39:38 UTC, IGotD- wrote:
> Typically RTOS in small platforms like STM32F4 or similar often don't implement TLS.

Don't worry - TLS implementation is trivial for each platform.

Am Wed, 17 Jun 2020 02:47:50 +0000 schrieb Adam D. Ruppe:

> On Tuesday, 16 June 2020 at 01:12:10 UTC, Andrei Alexandrescu wrote:
> 
>> My recollection is that we currently have a layering on top of the GC
>> that is based on a misunderstanding of how linkers work,
>> and also awkward and unnecessary.
> 
> the gc proxy thing is a mess yah.

Isn't the GC proxy only used for windows DLL support? IIRC we need it as we can't build druntime as a DLL right now.



-- 
Johannes

Am Wed, 17 Jun 2020 11:06:26 +0200 schrieb Jacob Carlborg:

> What about the TLS data, isn't that used for the GC? This data is retrieved eagerly when a new thread is started. But since you'll always have at least one thread the data will always be retrieved?

TLS memory is scanned by the GC, but it is managed / freed by the C library when a thread is stopped. Similar for static memory, which is as far as I know never freed. So as long as you don't have any heap memory, there's really no GC work to do.


-- 
Johannes

On Thursday, 18 June 2020 at 05:50:38 UTC, Denis Feklushkin wrote:
>
> Don't worry - TLS implementation is trivial for each platform.

For a static system which doesn't change, then yes it might be trivial. For a system that allows runtime loaded shared libraries, then no.

On Tuesday, 16 June 2020 at 01:08:16 UTC, Andrei Alexandrescu wrote:
> The new merged library ("hall" in honor of Asaph Hall who discovered Phobos and Deimos) would be built under a strict pay-as-you-go regime. That means an empty main uses virtually nothing, a main with a writeln() uses a little I/O, a main that allocates memory brings the GC in play (which auto-initializes on the first call), etc.

How would that interact with architecture-based constraints (e.g. issues porting libraries in their entirety because of architecture-specific limitations, missing assembly implementations, etc.)?

Is it possible to ensure there is a well-defined "pay for what you can" separation of concerns, as well as "pay-as-you-go"?

P.S. I think you should call the library Asaph, it's more distinctive ;-)

On 6/18/20 8:10 AM, Joseph Rushton Wakeling wrote:
> On Tuesday, 16 June 2020 at 01:08:16 UTC, Andrei Alexandrescu wrote:
>> The new merged library ("hall" in honor of Asaph Hall who discovered Phobos and Deimos) would be built under a strict pay-as-you-go regime. That means an empty main uses virtually nothing, a main with a writeln() uses a little I/O, a main that allocates memory brings the GC in play (which auto-initializes on the first call), etc.
> 
> How would that interact with architecture-based constraints (e.g. issues porting libraries in their entirety because of architecture-specific limitations, missing assembly implementations, etc.)?

I assume porting a pay-as-you-go library would be easier to port than a monolithic one.

> Is it possible to ensure there is a well-defined "pay for what you can" separation of concerns, as well as "pay-as-you-go"?

I don't know. That would be for the crack team that hasn't been assembled yet :o). What I can tell is that in a large project, whatever people pay attention to will work well. Whatever people don't pay attention to will work poorly. For example: in Phobos I paid little attention to things like object file size, linking in code, mutual dependencies, or separating memory allocation from other work. These aspects did not evolve well.

> P.S. I think you should call the library Asaph, it's more distinctive ;-)

Another decision for them!

On Thursday, 18 June 2020 at 13:17:14 UTC, Andrei Alexandrescu wrote:
> I don't know. That would be for the crack team that hasn't been assembled yet :o)

There are times I rather regret that I'm in a very busy job with lots to do ... :-)

>> P.S. I think you should call the library Asaph, it's more distinctive ;-)
>
> Another decision for them!

Sure, but it's the RIGHT decision ;-)