On Wednesday, 16 September 2015 at 18:34:48 UTC, Martin Nowak
wrote:
On Tuesday, 15 September 2015 at 08:39:43 UTC, John Colvin
wrote:
Where is the VERSION file documented? Why does it need manual
intervention only for patch releases and pre-releases?
We should prolly remove the manually updat
Dne 19.9.2015 v 21:30 Ola Fosheim Grøstad via Digitalmars-d-announce
napsal(a):
On Saturday, 19 September 2015 at 19:25:31 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 19 September 2015 at 19:17:38 UTC, Daniel Kozak wrote:
No, collection could not occure if we speaking about current D GC
imp
Hi everyone,
LDC 0.16.0 alpha4, the LLVM-based D compiler, is available for
download!
This release is based on the 2.067.1 frontend and standard
library and supports LLVM 3.1-3.7 (OS X: no support for 3.3).
Don't miss to check if your preferred system is supported by this
release. There is e
On Saturday, 19 September 2015 at 19:25:31 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 19 September 2015 at 19:17:38 UTC, Daniel Kozak
wrote:
No, collection could not occure if we speaking about current D
GC
implementation. So it safe to set pointer before addRoot.
It can be triggered by ano
On Saturday, 19 September 2015 at 19:17:38 UTC, Daniel Kozak
wrote:
No, collection could not occure if we speaking about current D
GC
implementation. So it safe to set pointer before addRoot.
It can be triggered by another thread.
Wrong:
ptr = somestack.pop();
someglobalptr = ptr;
// ptr reg
No, collection could not occure if we speaking about current D GC
implementation. So it safe to set pointer before addRoot.
Dne 19. 9. 2015 21:00 napsal uživatel "Ola Fosheim Grøstad via
Digitalmars-d-announce" :
> On Saturday, 19 September 2015 at 18:20:16 UTC, Ola Fosheim Grøstad wrote:
>
>> I'm
On Saturday, 19 September 2015 at 18:20:16 UTC, Ola Fosheim
Grøstad wrote:
I'm not sure if the current collector scans all registers, or
just scans the stack?
According to the docs it scans all registers, but even then one
must be careful and do addRoot before the pointer is set,
otherwise th
On Saturday, 19 September 2015 at 17:56:23 UTC, thedeemon wrote:
Yes, good point. One should keep root ranges small too.
If we carefully use addRoot() and addRange() for data directly
pointing to GC heap I think we don't need to let GC scan
everything that can lead to this data. This is error-p
On Saturday, 19 September 2015 at 09:22:40 UTC, Ola Fosheim
Grøstad wrote:
Please, let's stop pretending you only have to scan the GC
heap. You have to scan all pointers that somehow can lead to
something that can lead to something... that points into the GC
heap.
Yes, good point. One shoul
On Saturday, 19 September 2015 at 14:12:10 UTC, Rory McGuire
wrote:
The impression I got reading the article was that their GC was
very much like our current one except that the marking part of
the algorithm was run concurrently.
It is quite different. As mentioned they also protect writes to
The impression I got reading the article was that their GC was very much
like our current one except that the marking part of the algorithm was run
concurrently.
That is the only reason I shared the article. To me it seems one should be
to mark variables/types with which style of memory management
On Saturday, 19 September 2015 at 08:36:51 UTC, thedeemon wrote:
full heap every time. And that leads to different usage pattern
where GC heap should remain small and GC allocation rate low.
Please, let's stop pretending you only have to scan the GC heap.
You have to scan all pointers that som
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
The new GC in Go 1.5 seems interesting. What they say about is
certainly interesting.
They went the way of classical GC-ed language where write
barriers are used actively, allowing to make concurrent,
incremental and (eventually, if no
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
The new GC in Go 1.5 seems interesting. What they say about is
certainly interesting.
http://blog.golang.org/go15gc
Go 1.6 GC roadmap:
https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziAf0V27A64Mo/preview
On 18-Sep-2015 23:46, Jack Stouffer wrote:
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
[snip]
The reason Go has a better GC than D is that Go users have no choice but
to use the GC, while D users have a bunch more options.
To put it differently - D is a big language that has lot
15 matches
Mail list logo