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
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:
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/
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
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
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
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
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
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
{
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.
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
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
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
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
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
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
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
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
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
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
