On Sat, Apr 14, 2018 at 01:40:58AM +0200, Timon Gehr via Digitalmars-d wrote:
> On 13.04.2018 23:40, Jonathan M Davis wrote:
> > On Friday, April 13, 2018 22:36:31 Timon Gehr via Digitalmars-d wrote:
> > > On 10.04.2018 10:56, Jonathan M Davis wrote:
> > > > CTFE only ever happens when it must happen. The compiler never does it as an optimization.
> > > 
> > > The frontend doesn't. The backend might.
> > 
> > The optimizer may do constant folding or inline the code so far that it just gives the result, but it doesn't do actual CTFE. That's all in the frontend.
> > 
> > - Jonathan M Davis
> > 
> 
> CTFE just stands for "compile-time function evaluation". Claiming that the compiler never does this as an optimization is a bit misleading, but fine.

CTFE, as currently implemented in the compiler front-end (i.e., common across dmd, gdc, ldc), is actually only invoked when a value is *required* at compile-time, e.g., as a template argument or enum.  While the CTFE code did grow out of the constant-folding code, the two are actually distinct, and the front-end never calls CTFE when performing constant-folding (even though CTFE could be construed to be a souped-up form of constant-folding).  This is a rather fine distinction in the current implementation that I wasn't aware of until recently.

Certain backends, like ldc's, may also perform their own "compile-time function evaluation", e.g., on the LLVM IR, as part of their optimization pass.  For example, the LDC optimizer can literally execute LLVM IR at compile-time and replace an entire function-call tree with a single instruction that loads the computed value as a literal.  This has nothing to do with CTFE (as we know it in D) per se, but is a feature of the LDC optimizer.


T

-- 
It only takes one twig to burn down a forest.

On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
> How difficult would it be to migrate an existing modern GC-implementation into D's?
>
> Which kinds of GC's would be of interest?
>
> Which attempts have been made already?

IBM has open sourced its JVM:

https://www.eclipse.org/openj9/

They claim they have good GCs. So maybe someone knowledgeable wants to have a look at it.

On 5/24/18 8:35 AM, Chris wrote:
> On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
>> How difficult would it be to migrate an existing modern GC-implementation into D's?
>>
>> Which kinds of GC's would be of interest?
>>
>> Which attempts have been made already?
> 
> IBM has open sourced its JVM:
> 
> https://www.eclipse.org/openj9/
> 
> They claim they have good GCs. So maybe someone knowledgeable wants to have a look at it.

It's GPL, Apache, or EPL. I'm not sure about EPL, but I know that the former 2 are not convertible to Boost, so we couldn't accept a port from there.

Really though, the issues with D's GC are partly to blame from the language itself rather than the GC design. Having certain aspects of the language precludes certain GCs. Java as a language is much more conducive to more advanced GC designs.

-Steve

On Thursday, 24 May 2018 at 13:13:03 UTC, Steven Schveighoffer wrote:
> Really though, the issues with D's GC are partly to blame from the language itself rather than the GC design. Having certain aspects of the language precludes certain GCs. Java as a language is much more conducive to more advanced GC designs.

I'm hoping for a tough long-term deprecation process that alleviates these issues eventhough they will cause big breakage. I believe it will be worth it.