https://issues.dlang.org/show_bug.cgi?id=4719
Iain Buclaw changed:
What|Removed |Added
Priority|P2 |P4
--
On Wednesday, 2 October 2019 at 06:41:28 UTC, Rainer Schuetze
wrote:
thanks for the detailed answer
On 01/10/2019 18:24, a11e99z wrote:
> On Tuesday, 1 October 2019 at 16:12:18 UTC, a11e99z wrote:
>> does anybody some kind of benchmark to test conservative and precise GC?
>> precise GC is better or not? is STW improving?
Without false pointers the precise GC is usually a bit s
On Tuesday, 1 October 2019 at 16:24:49 UTC, a11e99z wrote:
why I want to know such info?
CodinGame sometimes use time-limit for bot move for example
100ms, and bot will be disqualified in case no answer
Simple solution: don't allocate every frame. The GC only runs
when it needs to and it
On Tuesday, 1 October 2019 at 16:12:18 UTC, a11e99z wrote:
does anybody some kind of benchmark to test conservative and
precise GC?
precise GC is better or not? is STW improving?
and another question about GC and app parameters:
program.exe “–DRT-gcopt=gc:precise parallel:4”
“–DRT
does anybody some kind of benchmark to test conservative and
precise GC?
precise GC is better or not? is STW improving?
On Thursday, 23 May 2019 at 15:25:31 UTC, Per Nordlöw wrote:
You mean wise versa, right?
Nevermind that comment. No "wise versa". You're answer is
correct, rikki cattermole.
Thanks
On Thursday, 23 May 2019 at 14:50:12 UTC, Per Nordlöw wrote:
How do I specify a druntime flag such as
--DRT-gcopt=gc:precise
when running with dub as
dub run --compiler=dmd --build=unittest
?
The precise GC flag was introduced in verison 2.085.0
See:
- https://dlang.org/changelog
On Thursday, 23 May 2019 at 15:05:15 UTC, rikki cattermole wrote:
Should be as easy as
dflags "--DRT-gcopt=gc:precise"
right?
That would be passed to dmd, not to the build executable upon
running.
You mean wise versa, right?
Now I understand,
--DRT-gcopt=gc:precise
is passed to
On 24/05/2019 3:03 AM, Per Nordlöw wrote:
On Thursday, 23 May 2019 at 15:02:12 UTC, rikki cattermole wrote:
And if I want to set this in a dub.sdl?
No can do. There is meant to be a way to set it in D however.
But I have heard mixed results (not that I've tried it).
Should be as easy as
On 24/05/2019 2:58 AM, Per Nordlöw wrote:
On Thursday, 23 May 2019 at 14:51:41 UTC, rikki cattermole wrote:
dub run --compiler=dmd --build=unittest -- --DRT-gcopt=gc:precise
Thanks!
And if I want to set this in a dub.sdl?
No can do. There is meant to be a way to set it in D however.
But I
On Thursday, 23 May 2019 at 15:02:12 UTC, rikki cattermole wrote:
And if I want to set this in a dub.sdl?
No can do. There is meant to be a way to set it in D however.
But I have heard mixed results (not that I've tried it).
Should be as easy as
dflags "--DRT-gcopt=gc:precise"
right?
On 24/05/2019 3:01 AM, Per Nordlöw wrote:
On Thursday, 23 May 2019 at 14:51:41 UTC, rikki cattermole wrote:
dub run --compiler=dmd --build=unittest -- --DRT-gcopt=gc:precise
Hmm, the flag doesn't propagate to dmd when compiling in verbose mode
via -v as
dub run -v --compiler=dmd
On Thursday, 23 May 2019 at 14:51:41 UTC, rikki cattermole wrote:
dub run --compiler=dmd --build=unittest --
--DRT-gcopt=gc:precise
Hmm, the flag doesn't propagate to dmd when compiling in verbose
mode via -v as
dub run -v --compiler=dmd --build=unittest --
--DRT-gcopt=gc:precise
On Thursday, 23 May 2019 at 14:51:41 UTC, rikki cattermole wrote:
dub run --compiler=dmd --build=unittest --
--DRT-gcopt=gc:precise
Thanks!
And if I want to set this in a dub.sdl?
How do I specify a druntime flag such as
--DRT-gcopt=gc:precise
when running with dub as
dub run --compiler=dmd --build=unittest
?
The precise GC flag was introduced in verison 2.085.0
See:
- https://dlang.org/changelog/2.085.0.html#gc_precise
- https://dlang.org/spec/garbage.html
On 24/05/2019 2:50 AM, Per Nordlöw wrote:
How do I specify a druntime flag such as
--DRT-gcopt=gc:precise
when running with dub as
dub run --compiler=dmd --build=unittest
dub run --compiler=dmd --build=unittest -- --DRT-gcopt=gc:precise
On 05/03/2019 22:30, H. S. Teoh wrote:
> On Tue, Mar 05, 2019 at 09:50:34PM +0100, Rainer Schuetze via
> Digitalmars-d-learn wrote:
>> On 04/03/2019 12:12, KnightMare wrote:
> [...]
>>> 3) closures: do the closures have any internal types that helps to
>>> GC or are they (full closure memory
On Tue, Mar 05, 2019 at 09:50:34PM +0100, Rainer Schuetze via
Digitalmars-d-learn wrote:
> On 04/03/2019 12:12, KnightMare wrote:
[...]
> > 3) closures: do the closures have any internal types that helps to
> > GC or are they (full closure memory block) scanned as in the
> > conservative mode?
>
On 04/03/2019 12:12, KnightMare wrote:
> For example, we have some rooted memory block as
> auto rooted = new long[1_000_000];
> 1) conservative-GC will scan it for false pointers every GC-cycle. is it
> true?
> 2) precise-GC will NOT scan it at all. is it true?
As A
or
structs with static blocks.
struct {
int a;
void* b;
}
The old GC would treat that whole struct as potentially pointers,
both a and b. The new precise GC would know only b needs to be
scanned inside that struct.
The even bigger deal with precise is it also knows only b would
need
IMO need more explanations about precise-GC and cases where
behavior of precise and conservative same and differs
/* English is not my native, and I tried to use Google translate.
I hope u will understand subtleties of questions */
For precise-GC:
3) closures: do the closures have any internal types that helps
to GC or are they (full closure memory block) scanned as in the
conservative mode?
4
As I understood conservative-GC scans all allocated memory blocks
for false pointers. In other hand precise-GC scans only explicit
memory blocks that contains (objects of types that contains)
pointers/refs or "muddy" types (void, void[]...).
For example, we have some rooted me
And 2k18 passes and there will be no precise gc this year it
seems.
Great D language. Better to think to move from it away.
On Monday, 27 November 2017 at 18:32:39 UTC, Ola Fosheim Grøstad
wrote:
You get this:
shared_ptr -> control_block -> object
Actually, seems like the common implementation uses 16 bytes, so
that it has a direct pointer as well. So twice the size of
unique_ptr.
On Monday, 27 November 2017 at 20:13:35 UTC, Dmitry Olshansky
wrote:
I’ve seen a tech giant that works on uber high-performance
things making heavy use of STL, and being fond of C++14
“high-level” features.
Look, I am not against "high level" features, but shared_ptr is
nothing like the
On Monday, 27 November 2017 at 18:29:56 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 27 November 2017 at 17:16:50 UTC, Dmitry Olshansky
wrote:
Really, shared_ptr is the most contagious primitive of modern
C++.
Not really. Unique_ptr is, though.
To quote MS STL guy “I’m surprised we had no
On Monday, 27 November 2017 at 18:00:59 UTC, Jonathan M Davis
wrote:
I don't understand this. I would expect most modern C++
programs to be using shared_ptr as the default for most
pointers and thus use it heavily.
You get this:
shared_ptr -> control_block -> object
Instead of this:
On Monday, 27 November 2017 at 17:16:50 UTC, Dmitry Olshansky
wrote:
Really, shared_ptr is the most contagious primitive of modern
C++.
Not really. Unique_ptr is, though.
To quote MS STL guy “I’m surprised we had no non-inteusive
ref-counted ptr in std lib for so long”.
Going Native videos
On Monday, November 27, 2017 15:56:09 Ola Fosheim Grostad via Digitalmars-d
wrote:
> On Monday, 27 November 2017 at 14:35:03 UTC, Dmitry Olshansky
>
> wrote:
> > Then watch Herb’s Sutter recent talk “Leak freedom by default”.
> > Now THAT guy must be out of his mind :)
>
> He could be, I havent
On Monday, 27 November 2017 at 15:56:09 UTC, Ola Fosheim Grostad
wrote:
On Monday, 27 November 2017 at 14:35:03 UTC, Dmitry Olshansky
wrote:
Then watch Herb’s Sutter recent talk “Leak freedom by
default”. Now THAT guy must be out of his mind :)
He could be, I havent seen it... Shared_ptr isnt
Btw, it would improve the discourse if people tried to
distinguish between language constructs and library constructs...
On Monday, 27 November 2017 at 14:35:03 UTC, Dmitry Olshansky
wrote:
Then watch Herb’s Sutter recent talk “Leak freedom by default”.
Now THAT guy must be out of his mind :)
He could be, I havent seen it... Shared_ptr isnt frequently used,
it is a last resort,
atomic_shared_pointer is
On Monday, 27 November 2017 at 07:03:01 UTC, Ola Fosheim Grostad
wrote:
On Monday, 27 November 2017 at 06:47:00 UTC, Dmitry Olshansky
wrote:
Last time I check shared_ptr can be safely shared across
threads, hence RC is takling synchronization and most likely
atomics since locks won’t be any
On Monday, 27 November 2017 at 10:13:41 UTC, codephantom wrote:
But in a discussion about GC, some technical details might
prove to be very useful to those of us following this
discussion.
Precise scanning of pointers makes sense when you have many
cachelines on the GC with no pointers in
On Monday, 27 November 2017 at 09:38:52 UTC, Temtaime wrote:
Current GC in D is shit
Can you elaborate?
"D is totally useless"..."Dlang is a toy in outer space"... "GC
in D is shit" ..
I'm very open minded to these different argument styles, and
occassionaly make use of them myself. But
On Monday, 27 November 2017 at 09:38:52 UTC, Temtaime wrote:
Please stop this flame
There is no flaming.
Current GC in D is shit and all this speaking won't improve
situation.
If so, why are you here? But you are fundamentally wrong. Precise
GC will not bring a general improvement
Please stop this flame and make first real step into bringing
precise GC to us.
Current GC in D is shit and all this speaking won't improve
situation.
The PR is not merged although it passed all the tests.
On Monday, 27 November 2017 at 07:09:25 UTC, Ola Fosheim Grostad
wrote:
But it kinda is missing the point that if it only is in a
single thread then it would typically only have only one
assignment. Shared_ptr is for holding a resource not for using
it...
Just to expand a bit on this: What
On Monday, 27 November 2017 at 06:59:30 UTC, Petar Kirov
[ZombineDev] wrote:
the shared_ptr itself) and you can't opt out of that even if
you're not sharing the shared_ptr with other threads.
Well, the compiler can in theory ellide atomics if it csn prove
that the memory cannot be accessed by
On Monday, 27 November 2017 at 06:47:00 UTC, Dmitry Olshansky
wrote:
Last time I check shared_ptr can be safely shared across
threads, hence RC is takling synchronization and most likely
atomics since locks won’t be any better.
The controlblock can, but it is crazy to use shared_ptr for
On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad
wrote:
On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky
wrote:
likely via RAII. Not to mention cheap (thread-local) Ref
Counting, C++ and many other language have to use atomics
which makes RC costly.
No, you dont.
On Monday, 27 November 2017 at 06:36:27 UTC, Ola Fosheim Grostad
wrote:
On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky
wrote:
likely via RAII. Not to mention cheap (thread-local) Ref
Counting, C++ and many other language have to use atomics
which makes RC costly.
No, you dont.
On Monday, 27 November 2017 at 05:47:49 UTC, Dmitry Olshansky
wrote:
likely via RAII. Not to mention cheap (thread-local) Ref
Counting, C++ and many other language have to use atomics which
makes RC costly.
No, you dont. Nobody in their right mind would do so in C++ as a
general solution.
“skip” write barriers in your @system code
because it may run as part of larger @safe. Which is where
they are the most costly.
I was thinking you would use a generational or precise GC for
@safe code and then fall back to the normal GC with
@system/@trusted code.
Wishful thinking. Memory
On Sunday, 26 November 2017 at 19:11:08 UTC, Jonathan M Davis
wrote:
It wouldn't work. @safe code and @system code call each other
all the time (using @trusted where necessary), and they freely
exchange stuff that was allocated on the GC heap. [snip]
I see. Fair enough.
On Sunday, 26 November 2017 at 19:11:08 UTC, Jonathan M Davis
wrote:
We can't even have different heaps for immutable and mutable
stuff, because it's very common to construct something as
mutable and then cast it to immutable (either explicitly or
This is easy to fix, introduce a uniquely
would be
> > cheaper to implement.
> >
> > Sadly you can’t “skip” write barriers in your @system code
> > because it may run as part of larger @safe. Which is where they
> > are the most costly.
>
> I was thinking you would use a generational or precise GC for
> @
as part of larger @safe. Which is where they
are the most costly.
I was thinking you would use a generational or precise GC for
@safe code and then fall back to the normal GC with
@system/@trusted code. Not sure if that's possible or not, but in
my head it would be a separate heap from
On Sunday, 26 November 2017 at 08:49:42 UTC, Dmitry Olshansky
wrote:
Sadly you can’t “skip” write barriers in your @system code
because it may run as part of larger @safe. Which is where they
Well, you can if you carefully lock the gc runtime or if you dont
modify existing scannable pointers
On Sunday, 26 November 2017 at 04:01:31 UTC, jmh530 wrote:
On Friday, 24 November 2017 at 05:53:37 UTC, Dmitry Olshansky
wrote:
A better GC is a great direction. Generational one is not
feasible unless we disallow quite a few of our features.
What about @safe?
If all of the code is 100%
On Friday, 24 November 2017 at 05:53:37 UTC, Dmitry Olshansky
wrote:
A better GC is a great direction. Generational one is not
feasible unless we disallow quite a few of our features.
What about @safe?
On Friday, 24 November 2017 at 07:48:03 UTC, Ola Fosheim Grøstad
wrote:
But I am not sure if Walter's goal is to attract as many users
as possible.
Given all the bullshit bugs I have to deal with, I'm starting to
think it's the opposite.
On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
a precise GC will enable data with isolated or immutable
indirections to
be safely moved between threads
I think you could in any case. What precise allows is to copy
object during collection if there is no conservative
On Friday, 24 November 2017 at 05:34:14 UTC, Adam Wilson wrote:
RAII+stack allocations make sense when I care about WHEN an
object is released and wish to provide some semblance of
control over deallocation (although as Andrei has pointed out
numerous time, you have no idea how many objects
On Friday, 24 November 2017 at 05:34:14 UTC, Adam Wilson wrote:
On 11/23/17 13:40, Ola Fosheim Grøstad wrote:
On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson
wrote:
I would focus on a generational GC first for two reasons. The
But generational GC only makes sense if many of your
On 11/23/17 13:40, Ola Fosheim Grøstad wrote:
On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
I would focus on a generational GC first for two reasons. The
But generational GC only makes sense if many of your GC objects have a
short life span. I don't think this fits well
On Thursday, 23 November 2017 at 20:13:31 UTC, Adam Wilson wrote:
I would focus on a generational GC first for two reasons. The
But generational GC only makes sense if many of your GC objects
have a short life span. I don't think this fits well with
sensible use of a language like D where
On 11/23/17 02:47, Nordlöw wrote:
On Wednesday, 22 November 2017 at 13:44:22 UTC, Nicholas Wilson wrote:
Thats a linker(?) limitation for OMF (or whatever is the win32 object
file format).
Was just fixed!
What improvements to D's concurrency model is made possible with this
precise GC?
I
On Wednesday, 22 November 2017 at 13:44:22 UTC, Nicholas Wilson
wrote:
Thats a linker(?) limitation for OMF (or whatever is the win32
object file format).
Was just fixed!
What improvements to D's concurrency model is made possible with
this precise GC?
I recall Martin Nowak saying at DConf
On 11/22/17 05:44, Nicholas Wilson wrote:
On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote:
On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
Hi all !
https://github.com/dlang/druntime/pull/1603
Only the Win32 build fails as
Error: more than 32767 symbols in
On Wednesday, 22 November 2017 at 13:23:54 UTC, Nordlöw wrote:
On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
Hi all !
https://github.com/dlang/druntime/pull/1603
Only the Win32 build fails as
Error: more than 32767 symbols in object file
What's wrong?
Thats a linker(?)
On Wednesday, 22 November 2017 at 10:53:45 UTC, Temtaime wrote:
Hi all !
https://github.com/dlang/druntime/pull/1603
Only the Win32 build fails as
Error: more than 32767 symbols in object file
What's wrong?
On 11/22/17 02:53, Temtaime wrote:
Hi all !
https://github.com/dlang/druntime/pull/1603
Can someone investigate and bring it to us ?
4 years passed from gsoc 2013 and there's still no gc.
Many apps suffers from false pointers and bringing such a gc will help
those who affected by it.
It seems
Hi all !
https://github.com/dlang/druntime/pull/1603
Can someone investigate and bring it to us ?
4 years passed from gsoc 2013 and there's still no gc.
Many apps suffers from false pointers and bringing such a gc will
help those who affected by it.
It seems all the tests are passed except
to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned,
it is closer than it was to be getting merged.
[...]
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan
wrote:
Hi,how about the precise GC, now?
I want to known too.
I was asked the same
So, who wants to do a good deed and make some money?
We can create an issue and start fundraising on Bountysource.
We can also donate to the D Language Foundation, but I personally
would like to see the funds were used to develop precise GC and
DIP74 (https://wiki.dlang.org/DIP74).
On Wednesday, 23 November 2016 at 04:27:58 UTC, Dsby wrote:
On Tuesday, 22 November 2016 at 11:20:10 UTC, Jack Applegame
wrote:
We look forward to sane GC over the years. How do we
accelerate the development of precise GC, RC and so on?
Maybe we should organize a fundraiser on Kickstarter
Dsby wrote:
On Tuesday, 22 November 2016 at 11:20:10 UTC, Jack Applegame wrote:
We look forward to sane GC over the years. How do we accelerate the
development of precise GC, RC and so on?
Maybe we should organize a fundraiser on Kickstarter or somewhere else?
I'm not ready to write precise GC
On Tuesday, 22 November 2016 at 11:20:10 UTC, Jack Applegame
wrote:
We look forward to sane GC over the years. How do we accelerate
the development of precise GC, RC and so on?
Maybe we should organize a fundraiser on Kickstarter or
somewhere else?
I'm not ready to write precise GC, but I'm
We look forward to sane GC over the years. How do we accelerate
the development of precise GC, RC and so on?
Maybe we should organize a fundraiser on Kickstarter or somewhere
else?
I'm not ready to write precise GC, but I'm willing to donate to
those who are ready.
On Monday, 17 October 2016 at 02:59:15 UTC, Dsby wrote:
On Friday, 14 October 2016 at 03:26:31 UTC, FrankLike wrote:
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan
wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC
On Friday, 14 October 2016 at 03:26:31 UTC, FrankLike wrote:
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan
wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned, it
is closer than
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned, it
is closer than it was to be getting merged.
[...]
On Friday, 2 September 2016 at 03:25
On Wednesday, 7 September 2016 at 02:15:30 UTC, Dsby wrote:
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan
wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned, it
is closer than
and independent,
as I understand.
This is correct, but when designing a GC – in particular, a
precise GC –, having the compiler emit additional helpful
metadata to binaries is always an option worth considering.
— David
On Tuesday, 6 September 2016 at 14:56:15 UTC, jmh530 wrote:
GC (and runtime in general) has no idea what code is safe and
what code is system. GC works with data at run-time. All
@safe-related stuff is about code (not data!) and happens at
compile-time. They are completely orthogonal and
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned, it
is closer than it was to be getting merged.
[...]
In Mac 32 bit. the test is not pass.
On Saturday, 3 September 2016 at 12:22:25 UTC, thedeemon wrote:
GC (and runtime in general) has no idea what code is safe and
what code is system. GC works with data at run-time. All
@safe-related stuff is about code (not data!) and happens at
compile-time. They are completely orthogonal and
On Friday, 2 September 2016 at 14:55:26 UTC, jmh530 wrote:
Anyway, with @safe unions, my thinking is that it would mean
that the garbage collector can be made precise in @safe code in
a way that it can't in @system code (assuming unions with
pointers aren't snuck in through @trusted).
GC
On Friday, 2 September 2016 at 08:14:33 UTC, Rory McGuire wrote:
Can we rather just make a special tagged union that is
scanned... rather avoid trying to make something that should be
minimal more and more complex? The compiler already treats some
parts of phobos as "special" as far as I
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote:
Through the work I did and the research of a couple of GC
topics, I discovered that I really enjoyed working on the
garbage collector and I plan on continuing that. I was recently
accepted to the University of Washington's
On Fri, Sep 2, 2016 at 9:46 AM, Jeremy DeHaan via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> [snip]. Precisely scanning unions is tricky since they could mix pointer
> and non pointer types. [snip]
>
Can we rather just make a special tagged union that is scanned...
On Friday, 2 September 2016 at 06:54:57 UTC, Ali Çehreli wrote:
On 09/01/2016 08:25 PM, Jeremy DeHaan wrote:
> I will still continue working on it in the hopes it'll get in.
Great news! :)
> I
> discovered that I really enjoyed working on the garbage
collector
If that's not motivation
On Friday, 2 September 2016 at 05:19:57 UTC, thedeemon wrote:
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan
wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned, it
is closer than
On 09/01/2016 08:25 PM, Jeremy DeHaan wrote:
> I will still continue working on it in the hopes it'll get in.
Great news! :)
> I
> discovered that I really enjoyed working on the garbage collector
If that's not motivation enough...
> I was recently accepted to the University of Washington's
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned, it
is closer than it was to be getting merged.
My open PR for the actual inclusion
On 02/09/2016 3:25 PM, Jeremy DeHaan wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for that. While
my work on the precise GC didn't go as planned, it is closer than it was
to be getting merged.
My open PR for the actual inclusion of the precise GC is here:
https
On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote:
Hi everyone,
I know I'm super late to the party for this, and sorry for
that. While my work on the precise GC didn't go as planned, it
is closer than it was to be getting merged.
[...]
wait for merge
Hi everyone,
I know I'm super late to the party for this, and sorry for that.
While my work on the precise GC didn't go as planned, it is
closer than it was to be getting merged.
My open PR for the actual inclusion of the precise GC is here:
https://github.com/dlang/druntime/pull/1603
Even
I look the DIP in the wiki: http://wiki.dlang.org/DIP74
and in GSOC
,https://forum.dlang.org/thread/jcfwcdvvfytdkjrpd...@forum.dlang.org
which will be come true nearest。
On Sunday, 8 May 2016 at 11:16:56 UTC, deadalnix wrote:
Ones that have only pointers are probably OK too. Though I'm
not sure if a precise scanner takes into account the type of
the pointer. I would expect it to use embedded typeinfo in
target block.
-Steve
Because of void* and classes,
On Friday, 6 May 2016 at 09:06:59 UTC, Dmitry Olshansky wrote:
On 06-May-2016 05:37, Jeremy DeHaan wrote:
On Wednesday, 4 May 2016 at 12:42:30 UTC, jmh530 wrote:
On Wednesday, 4 May 2016 at 02:50:08 UTC, Jeremy DeHaan wrote:
You can identify safe functions with
On Friday, 6 May 2016 at 09:31:08 UTC, Steven Schveighoffer wrote:
On 5/6/16 11:06 AM, Dmitry Olshansky wrote:
On 06-May-2016 05:37, Jeremy DeHaan wrote:
On Wednesday, 4 May 2016 at 12:42:30 UTC, jmh530 wrote:
On Wednesday, 4 May 2016 at 02:50:08 UTC, Jeremy DeHaan
wrote:
I'm not sure, but
On Tuesday, 3 May 2016 at 18:15:20 UTC, Jeremy DeHaan wrote:
Not sure if it is something I can get to in the course of my
project though. Scanning only unions conservatively is still
pretty good.
And the stack, and the CPU registers, but yeah, it should be a
minority.
On 5/6/16 11:06 AM, Dmitry Olshansky wrote:
On 06-May-2016 05:37, Jeremy DeHaan wrote:
On Wednesday, 4 May 2016 at 12:42:30 UTC, jmh530 wrote:
On Wednesday, 4 May 2016 at 02:50:08 UTC, Jeremy DeHaan wrote:
I'm not sure, but one would think that @safe code wouldn't need any
extra information
On 06-May-2016 05:37, Jeremy DeHaan wrote:
On Wednesday, 4 May 2016 at 12:42:30 UTC, jmh530 wrote:
On Wednesday, 4 May 2016 at 02:50:08 UTC, Jeremy DeHaan wrote:
I'm not sure, but one would think that @safe code wouldn't need any
extra information about the union. I wouldn't know how to
On Wednesday, 4 May 2016 at 12:42:30 UTC, jmh530 wrote:
On Wednesday, 4 May 2016 at 02:50:08 UTC, Jeremy DeHaan wrote:
I'm not sure, but one would think that @safe code wouldn't
need any extra information about the union. I wouldn't know
how to differentiate between them though during
On Wednesday, 4 May 2016 at 02:50:08 UTC, Jeremy DeHaan wrote:
I'm not sure, but one would thing that @safe code wouldn't need
any extra information about the union. I wouldn't know how to
differentiate between them though during runtime. Probably
someone with more experience with the
1 - 100 of 283 matches
Mail list logo
