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 adv
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:
ht
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/
The
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 happ
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.
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 foldin
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.
On Wednesday, 11 April 2018 at 19:38:59 UTC, Dmitry Olshansky
wrote:
On Tuesday, 10 April 2018 at 07:22:14 UTC, David Bennett wrote:
People cast from thread local to shared? ...okay thats no
fun... :(
I can understand the other way, thats why i was leaning on the
conservative side and puttin
On Tuesday, 10 April 2018 at 06:47:53 UTC, Jonathan M Davis wrote:
As it stands, it's impossible to have thread-local memory
pools. It's quite legal to construct an object as shared or
thread-local and cast it to the other. In fact, it's _highly_
likely that that's how any shared object of any
On Tuesday, 10 April 2018 at 07:22:14 UTC, David Bennett wrote:
On Tuesday, 10 April 2018 at 06:43:28 UTC, Dmitry Olshansky
wrote:
On Tuesday, 10 April 2018 at 06:10:10 UTC, David Bennett wrote:
I was thinking about messing with the GC in my free time just
yesterday... how hard would it be:
[
On Tuesday, 10 April 2018 at 18:31:28 UTC, Jacob Carlborg wrote:
On 2018-04-10 08:47, Jonathan M Davis wrote:
Regardless, I think that it's clear that in order to do
anything with
thread-local pools, we'd have to lock down the type system
even further to
disallow casts to or from shared or imm
On 2018-04-10 08:47, Jonathan M Davis wrote:
Regardless, I think that it's clear that in order to do anything with
thread-local pools, we'd have to lock down the type system even further to
disallow casts to or from shared or immutable, and that would really be a
big problem given the inherent r
On 4/10/18 4:37 AM, David Bennett wrote:
On Tuesday, 10 April 2018 at 08:10:32 UTC, Jonathan M Davis wrote:
Yes. They expect it to work, and as the language is currently
designed, it works perfectly well. In fact, it's even built into the
language. e.g.
int[] foo() pure
{
re
On Tuesday, April 10, 2018 08:37:47 David Bennett via Digitalmars-d wrote:
> On Tuesday, 10 April 2018 at 08:10:32 UTC, Jonathan M Davis wrote:
> > Yes. They expect it to work, and as the language is currently
> > designed, it works perfectly well. In fact, it's even built
> > into the language. e.
On Tuesday, 10 April 2018 at 08:10:32 UTC, Jonathan M Davis wrote:
Yes. They expect it to work, and as the language is currently
designed, it works perfectly well. In fact, it's even built
into the language. e.g.
int[] foo() pure
{
return [1, 2, 3, 4];
}
void main()
On Tuesday, April 10, 2018 07:55:00 David Bennett via Digitalmars-d wrote:
> On Tuesday, 10 April 2018 at 06:47:53 UTC, Jonathan M Davis wrote:
> > As it stands, it's impossible to have thread-local memory
> > pools. It's quite legal to construct an object as shared or
> > thread-local and cast it
On Tuesday, 10 April 2018 at 06:47:53 UTC, Jonathan M Davis wrote:
As it stands, it's impossible to have thread-local memory
pools. It's quite legal to construct an object as shared or
thread-local and cast it to the other. In fact, it's _highly_
likely that that's how any shared object of any
On Tuesday, 10 April 2018 at 06:43:28 UTC, Dmitry Olshansky wrote:
On Tuesday, 10 April 2018 at 06:10:10 UTC, David Bennett wrote:
I was thinking about messing with the GC in my free time just
yesterday... how hard would it be:
[snip]
Lost immutable and that thread-local is often casted to
On Tuesday, April 10, 2018 06:10:10 David Bennett via Digitalmars-d wrote:
> On Tuesday, 10 April 2018 at 05:26:28 UTC, Dmitry Olshansky wrote:
> > On Monday, 9 April 2018 at 19:50:16 UTC, H. S. Teoh wrote:
> >> Last I remembered, you were working on a GC prototype for D?
> >
> > Still there, but m
On Tuesday, 10 April 2018 at 06:10:10 UTC, David Bennett wrote:
On Tuesday, 10 April 2018 at 05:26:28 UTC, Dmitry Olshansky
wrote:
On Monday, 9 April 2018 at 19:50:16 UTC, H. S. Teoh wrote:
Last I remembered, you were working on a GC prototype for D?
Still there, but my spare time is super li
On Tuesday, 10 April 2018 at 06:10:10 UTC, David Bennett wrote:
I was thinking about messing with the GC in my free time just
yesterday... how hard would it be:
[snip]
The idea is it works like it does currently unless something is
invisible to other threads, Or am i missing something obvious
On Tuesday, 10 April 2018 at 05:26:28 UTC, Dmitry Olshansky wrote:
On Monday, 9 April 2018 at 19:50:16 UTC, H. S. Teoh wrote:
Last I remembered, you were working on a GC prototype for D?
Still there, but my spare time is super limited lately, the
other project preempted that for the moment.
On Tuesday, 10 April 2018 at 03:59:33 UTC, Ikeran wrote:
On Monday, 9 April 2018 at 19:43:00 UTC, Dmitry Olshansky wrote:
None of of even close to advanced GCs are pluggable
Eclipse OMR contains a pluggable GC, and it's used in OpenJ9,
Or rather Eclipse OMR is a toolkit for runtimes/VMs and
On Monday, 9 April 2018 at 19:50:16 UTC, H. S. Teoh wrote:
On Mon, Apr 09, 2018 at 07:43:00PM +, Dmitry Olshansky via
Digitalmars-d wrote:
On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
[...]
> Which kinds of GC's would be of interest?
I believe we can get away with parallel
On Monday, 9 April 2018 at 19:43:00 UTC, Dmitry Olshansky wrote:
None of of even close to advanced GCs are pluggable
Eclipse OMR contains a pluggable GC, and it's used in OpenJ9,
which claims to be an enterprise-grade JVM.
On Monday, 9 April 2018 at 23:21:23 UTC, Nordlöw wrote:
Through allocators solely or will the GC adapt in some way?
Here is the relevant line from the vision document
"@nogc: Use of D without a garbage collector, most likely by
using reference counting and related methods Unique/Weak
referenc
On Monday, April 09, 2018 23:21:23 Nordlöw via Digitalmars-d wrote:
> On Monday, 9 April 2018 at 20:20:39 UTC, Ali 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 kin
On Monday, 9 April 2018 at 20:20:39 UTC, Ali 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?
I think the pr
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?
I think the priority is not having pluggable GC's, or a better
GC,
On Mon, Apr 09, 2018 at 07:43:00PM +, Dmitry Olshansky via Digitalmars-d
wrote:
> On Monday, 9 April 2018 at 18:27:26 UTC, Per Nordlöw wrote:
[...]
> > Which kinds of GC's would be of interest?
>
> I believe we can get away with parallel mark-sweep + snapshot-based
> concurrency. It has some
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 one? None of of even close to advanced GCs are pluggable,
most in addition to being hardwired to a runtime/VM codebase,
also rely on things lik
On Monday, 9 April 2018 at 18:39:11 UTC, Jack Stouffer 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?
Considering no one has done it, very.
What's the reason for this being so hard?
A too
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?
Considering no one has done it, very.
Which kinds of GC's would be of interest?
There's been threads about this. I'd do a search for "precise GC"
33 matches
Mail list logo