On Wednesday, 9 March 2016 at 22:49:28 UTC, Jeremy DeHaan wrote:
Hey all,
I'm trying to think of good project ideas for this years GSoC,
and one in particular I thought would be a great was working on
and improving the GC. I'm not sure what the scope of this
project would be like, but at the
Jeremy DeHaan wrote:
Hey all,
I'm trying to think of good project ideas for this years GSoC, and one
in particular I thought would be a great was working on and improving
the GC. I'm not sure what the scope of this project would be like, but
at the moment I am thinking writing a generational col
On Wednesday, 9 March 2016 at 22:49:28 UTC, Jeremy DeHaan wrote:
Hey all,
I'm trying to think of good project ideas for this years GSoC,
and one in particular I thought would be a great was working on
and improving the GC. I'm not sure what the scope of this
project would be like, but at the
On Thursday, 10 March 2016 at 05:01:37 UTC, Joakim wrote:
Perhaps someone could build off of Sociomantic's concurrent GC
(https://www.sociomantic.com/blog/2013/06/porting-cdgc-to-d2/),
which I assume has been ported to D2, porting it to Windows or
whatever else remains to be done and then addin
On Thursday, 10 March 2016 at 11:12:47 UTC, thedeemon wrote:
On Thursday, 10 March 2016 at 05:01:37 UTC, Joakim wrote:
Perhaps someone could build off of Sociomantic's concurrent GC
(https://www.sociomantic.com/blog/2013/06/porting-cdgc-to-d2/), which I assume has been ported to D2, porting it t
On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it lock-free.
Currently, GC lock cause some serious performance penalties for
multithreaded code when frequent allocations take place.
I agree. A first step would be easy to do with std.allocator's
thread-loca
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it
lock-free.
Currently, GC lock cause some serious performance penalties for
multithreaded code when frequent allocations take place.
I
On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan wrote:
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it
lock-free.
Currently, GC lock cause some serious performance penalties
Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan wrote:
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei Alexandrescu wrote:
On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it lock-f
On Thursday, 10 March 2016 at 17:46:15 UTC, Daniel Kozak wrote:
Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan
wrote:
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei
Alexandrescu wrote:
On 3/9/16 10:40 PM, NX wrote:
Dne 10.3.2016 v 19:39 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 17:46:15 UTC, Daniel Kozak wrote:
Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan wrote:
On Thursday, 10 March 2016 at 15:24:4
On Thursday, 10 March 2016 at 18:49:28 UTC, Daniel Kozak wrote:
Dne 10.3.2016 v 19:39 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 17:46:15 UTC, Daniel Kozak wrote:
Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 16:46:59
Thank you all for the feedback.
I think I might still need a little more feedback as to what the
project should actually entail, but here's what it's looking like
so far:
Implement lock free allocation using std.experimental.allocator's
freelists (SharedFreeList? It was the only thing in the
On 12/03/16 4:13 AM, Jeremy DeHaan wrote:
Thank you all for the feedback.
I think I might still need a little more feedback as to what the project
should actually entail, but here's what it's looking like so far:
Implement lock free allocation using std.experimental.allocator's
freelists (Share
Jeremy DeHaan wrote:
Thank you all for the feedback.
I think I might still need a little more feedback as to what the project
should actually entail, but here's what it's looking like so far:
Implement lock free allocation using std.experimental.allocator's
freelists (SharedFreeList? It was the
On Sat, 12 Mar 2016 00:50:06 -0800, Adam Wilson wrote:
> If I may make a suggestion. The lock free work is unlikely to require
> the entirety of GSoC. And the precise GC is the next most important
> thing on your list and will have the biggest impact on GC performance.
>
> Once the GC is fully pre
On Saturday, 12 March 2016 at 08:50:06 UTC, Adam Wilson wrote:
If I may make a suggestion. The lock free work is unlikely to
require the entirety of GSoC. And the precise GC is the next
most important thing on your list and will have the biggest
impact on GC performance.
Rainer has two differ
Jeremy DeHaan wrote:
On Saturday, 12 March 2016 at 08:50:06 UTC, Adam Wilson wrote:
If I may make a suggestion. The lock free work is unlikely to require
the entirety of GSoC. And the precise GC is the next most important
thing on your list and will have the biggest impact on GC performance.
R
On Sat, 12 Mar 2016 13:23:35 -0800, Adam Wilson wrote:
To start off, let's talk terminology. You seem to be using nonstandard
terminology and possibly misunderstanding standard terminology.
A GC scan is the mark phase of a mark/sweep collector (and specifically
the part where the GC examines ro
On 11-Mar-2016 18:13, Jeremy DeHaan wrote:
Thank you all for the feedback.
I think I might still need a little more feedback as to what the project
should actually entail, but here's what it's looking like so far:
Implement lock free allocation using std.experimental.allocator's
freelists (Shar
Chris Wright wrote:
On Sat, 12 Mar 2016 13:23:35 -0800, Adam Wilson wrote:
To start off, let's talk terminology. You seem to be using nonstandard
terminology and possibly misunderstanding standard terminology.
A GC scan is the mark phase of a mark/sweep collector (and specifically
the part wher
On Sun, 13 Mar 2016 12:43:37 -0700, Adam Wilson wrote:
>> A "partially moving" GC does not exist, as far as I know.
>>
>>
> Yep, it's a Bad Idea.
It's not a standard term. Google's only seeing about four references to
the term, none of them authoritative or definitive. Since it's non-
standard, i
Chris Wright wrote:
On Sun, 13 Mar 2016 12:43:37 -0700, Adam Wilson wrote:
A "partially moving" GC does not exist, as far as I know.
Yep, it's a Bad Idea.
It's not a standard term. Google's only seeing about four references to
the term, none of them authoritative or definitive. Since it's n
On Sunday, 13 March 2016 at 23:34:44 UTC, Adam Wilson wrote:
Is there an implementation of a conservative moving
(compacting) GC out there? I'm not aware of one, but there are
a lot of GC's out there. Boehm isn't.
That is impossible, you need to know what is and isn't a pointer
to be able t
On Sun, 13 Mar 2016 23:46:51 +, deadalnix wrote:
> On Sunday, 13 March 2016 at 23:34:44 UTC, Adam Wilson wrote:
>> Is there an implementation of a conservative moving (compacting) GC out
>> there? I'm not aware of one, but there are a lot of GC's out there.
>> Boehm isn't.
>>
>>
> That is impo
On Sun, 13 Mar 2016 16:34:44 -0700, Adam Wilson wrote:
> Is this a debate about precise vs. non-precise GC or are we just
> bikeshedding about terminology and technical details?
You made a large number of assertions about garbage collection and they
were almost all wrong.
It's not about minutiae
Chris Wright wrote:
On Sun, 13 Mar 2016 16:34:44 -0700, Adam Wilson wrote:
Is this a debate about precise vs. non-precise GC or are we just
bikeshedding about terminology and technical details?
You made a large number of assertions about garbage collection and they
were almost all wrong.
It's
deadalnix wrote:
On Sunday, 13 March 2016 at 23:34:44 UTC, Adam Wilson wrote:
Is there an implementation of a conservative moving (compacting) GC
out there? I'm not aware of one, but there are a lot of GC's out
there. Boehm isn't.
That is impossible, you need to know what is and isn't a point
On Monday, 14 March 2016 at 01:38:50 UTC, Adam Wilson wrote:
Lastly, Rainer seemed to think a precise GC could be done, and
he then went and did it ... so "can't reasonably have a precise
collector" is a factually incorrect assertion.
IIRC, Rainer called it "mostly precise", and for a good rea
thedeemon wrote:
On Monday, 14 March 2016 at 01:38:50 UTC, Adam Wilson wrote:
Lastly, Rainer seemed to think a precise GC could be done, and he then
went and did it ... so "can't reasonably have a precise collector" is
a factually incorrect assertion.
IIRC, Rainer called it "mostly precise", a
I haven't had power for a couple of days, but it looks like the
discussion has gone along pretty ok. After reading everything, I
think I'm inclined to agree with Adam and the main focus of my
proposal will be a precise GC (or as precise as we can get). I'll
definitely need some guidance, but I'
On Tuesday, 15 March 2016 at 01:34:07 UTC, Jeremy DeHaan wrote:
I haven't had power for a couple of days, but it looks like the
discussion has gone along pretty ok.
I would characterize it as very interesting, although I know very
little about how GCs are implemented.
I have a question, for
Jeremy DeHaan wrote:
I haven't had power for a couple of days, but it looks like the
discussion has gone along pretty ok. After reading everything, I think
I'm inclined to agree with Adam and the main focus of my proposal will
be a precise GC (or as precise as we can get). I'll definitely need so
On Tuesday, 15 March 2016 at 01:34:07 UTC, Jeremy DeHaan wrote:
I haven't had power for a couple of days, but it looks like the
discussion has gone along pretty ok. After reading everything,
I think I'm inclined to agree with Adam and the main focus of
my proposal will be a precise GC (or as pr
On 18.03.2016 22:04, Jeremy deHaan wrote:
On Friday, 18 March 2016 at 16:41:21 UTC, Rainer Schuetze wrote:
On 15.03.2016 02:34, Jeremy DeHaan wrote:
[...]
Being always way behind reading the forum these days, I'm a little
late and have not read all the messages in this thread thoroughly.
On 15.03.2016 02:34, Jeremy DeHaan wrote:
I haven't had power for a couple of days, but it looks like the
discussion has gone along pretty ok. After reading everything, I think
I'm inclined to agree with Adam and the main focus of my proposal will
be a precise GC (or as precise as we can get).
On Friday, 18 March 2016 at 16:41:21 UTC, Rainer Schuetze wrote:
On 15.03.2016 02:34, Jeremy DeHaan wrote:
[...]
Being always way behind reading the forum these days, I'm a
little late and have not read all the messages in this thread
thoroughly. Here are some thoughts:
[...]
Thank you
Rainer Schuetze wrote:
On 18.03.2016 22:04, Jeremy deHaan wrote:
On Friday, 18 March 2016 at 16:41:21 UTC, Rainer Schuetze wrote:
On 15.03.2016 02:34, Jeremy DeHaan wrote:
[...]
Being always way behind reading the forum these days, I'm a little
late and have not read all the messages in
38 matches
Mail list logo