On Wednesday, 29 January 2020 at 21:10:53 UTC, Steven
Schveighoffer wrote:
I'm pretty sure std.concurrency uses Variant to pass message
data, which boxes when it gets over a certain size. You are
probably crossing that threshold.
The allocations should level out eventually when the GC s
On 1/29/20 2:48 PM, cc wrote:
Given the sample program at https://pastebin.com/u9sSNtj7
I'm experiencing GC allocations with every call to std.concurrency.send
when sending larger messages (e.g. multiple ulongs). These do not occur
when sending uints in comparison, in the provided ex
Given the sample program at https://pastebin.com/u9sSNtj7
I'm experiencing GC allocations with every call to
std.concurrency.send when sending larger messages (e.g. multiple
ulongs). These do not occur when sending uints in comparison, in
the provided example.
For example, whe
the garbage collector in exchange for
memory is an interesting concept. But I wonder how quickly it
will get eaten up. ALSO, if I do shut it off, when i turn it on
is it going to take much longer? Does the GC take linear /
quadratically more time based on the N of "items need to be
freed&qu
Creates a Task on the GC heap that calls an alias.
If possible, there's also scopedTask, which allocates on the stack:
https://dlang.org/phobos/std_parallelism.html#.scopedTask
So my question is: Has anyone done any analysis over how "dangerous" it is to use GC'd tasks fo
You can control when the gc runs. So if you know the allocations
are small enough that they won't OOM, then you can say
GC.disable, and it straight up won't run at all. But you can
manually run a collection cycle (during a loading screen or
whatever) with GC.collect.
On Sat, Jan 04, 2020 at 12:51:15AM +, Chris Katko via Digitalmars-d-learn
wrote:
[...]
> I'm looking through D's parallelism module and the docs state,
> up-front:
>
> >Creates a Task on the GC heap that calls an alias.
>
> The modern, scalable way to make a
as is_deleted=true and re-using "dead" ones.]
I'm looking through D's parallelism module and the docs state,
up-front:
>Creates a Task on the GC heap that calls an alias.
The modern, scalable way to make a parallel game engine uses
tasks. (as opposed to functional decompo
On Friday, 15 November 2019 at 11:32:07 UTC, Basile B. wrote:
TBH I see your point but D is a system programming language.
Even if there's a GC you can also do Manual Memory Mangement
(sometimes you'll see "MMM "to refer to that in the forums),
RC, and you can also write
On Friday, 15 November 2019 at 10:55:55 UTC, IGotD- wrote:
On Friday, 15 November 2019 at 08:58:43 UTC, user1234 wrote:
On Wednesday, 13 November 2019 at 11:07:12 UTC, IGotD- wrote:
I'm trying to find the rationale why GC pointers (should be
names managed pointers) are using the exact
On Friday, 15 November 2019 at 08:58:43 UTC, user1234 wrote:
On Wednesday, 13 November 2019 at 11:07:12 UTC, IGotD- wrote:
I'm trying to find the rationale why GC pointers (should be
names managed pointers) are using the exact same type as any
other pointer.
Doesn't this limit the
On Wednesday, 13 November 2019 at 11:07:12 UTC, IGotD- wrote:
I'm trying to find the rationale why GC pointers (should be
names managed pointers) are using the exact same type as any
other pointer.
Doesn't this limit the ability to change the default GC type?
Doesn't this co
retained the special syntax for GC
pointers.
One of the motivations if I understand correctly is to let the
programmers easily distinguish which pointers should be freed
and which ones are managed by the GC. It's not a bad idea when
there is extensive use of both manual memory managemen
ver as an interesting
example where MS extended C++ with a ^gc type.
AFAIK those managed pointers are not general purpose, but
specifically for managed .net objects, you can't allocate
unmanaged object on managed heap, and managed object on unmanaged
heap. In case of D you would have
On Sunday, 10 November 2019 at 07:57:38 UTC, dangbinghoo wrote:
On Sunday, 3 November 2019 at 05:46:53 UTC, 9il wrote:
On Thursday, 31 October 2019 at 03:56:56 UTC, lili wrote:
Hi:
why writeln need GC?
See also Mir's @nogc formatting module
https://github.com/libmir/mir-runtime
On Wednesday, 13 November 2019 at 16:43:27 UTC, IGotD- wrote:
Best example is probably managed C++, an MS extension to C++
which is now deprecated.
MS Managed C++ was superseded by C++/CLI[1] which was
standardized. They actually retained the special syntax for GC
pointers.
One of the
s "raw". So you cannot put it
to C-allocated arrays without type casting, which you probably
don't do accidently.
Best example is probably managed C++, an MS extension to C++
which is now deprecated. However, it server as an interesting
example where MS extende
On Wednesday, 13 November 2019 at 11:07:12 UTC, IGotD- wrote:
I'm trying to find the rationale why GC pointers (should be
names managed pointers) are using the exact same type as any
other pointer.
Doesn't this limit the ability to change the default GC type?
What does grabage coll
On Wednesday, 13 November 2019 at 11:07:12 UTC, IGotD- wrote:
I'm trying to find the rationale why GC pointers (should be
names managed pointers) are using the exact same type as any
other pointer.
I assume you mean a GC that scans (not ref counting). GC pointers
only need to be prot
I'm trying to find the rationale why GC pointers (should be names
managed pointers) are using the exact same type as any other
pointer.
Doesn't this limit the ability to change the default GC type?
Doesn't this confusion make GC pointers just as unsafe as raw
pointers?
Has
If your goal is to debug your @nogc code, you can use writeln in
debug statement:
@nogc void main() {
debug writeln("hello, debug world!");
}
On Monday, 11 November 2019 at 16:20:59 UTC, bauss wrote:
If you wanted to follow the standard of D then you didn't need
a string type. Since it doesn't really exist in D.
string is just an alias for immutable(char)[]
And that is why std.exception.assumeUnique converts char[] to
string AKA
On Saturday, 9 November 2019 at 22:03:03 UTC, Ferhat Kurtulmuş
wrote:
On Thursday, 31 October 2019 at 03:56:56 UTC, lili wrote:
Hi:
why writeln need GC?
Upon this post, I thought writing a gc-free writeln would be a
good learning practice. Although it is not a feature-complete
one, it
On Sunday, 3 November 2019 at 05:46:53 UTC, 9il wrote:
On Thursday, 31 October 2019 at 03:56:56 UTC, lili wrote:
Hi:
why writeln need GC?
See also Mir's @nogc formatting module
https://github.com/libmir/mir-runtime/blob/master/source/mir/format.d
hi, is mir right now fully implem
On Thursday, 31 October 2019 at 03:56:56 UTC, lili wrote:
Hi:
why writeln need GC?
Upon this post, I thought writing a gc-free writeln would be a
good learning practice. Although it is not a feature-complete
one, it was a lot of fun to do it :)
https://github.com/aferust/stringnogc
On Thursday, 31 October 2019 at 03:56:56 UTC, lili wrote:
Hi:
why writeln need GC?
See also Mir's @nogc formatting module
https://github.com/libmir/mir-runtime/blob/master/source/mir/format.d
On Thursday, 31 October 2019 at 16:03:22 UTC, bachmeier wrote:
On Thursday, 31 October 2019 at 15:11:42 UTC, Ferhat Kurtulmuş
wrote:
It would be nice if one reimplement writeln of Phobos by
bypassing gc and use a custom nogc exception as described
here*? Of course I can imagine that it would
On Thursday, October 31, 2019 9:11:42 AM MDT Ferhat Kurtulmuş via
Digitalmars-d-learn wrote:
> On Thursday, 31 October 2019 at 13:46:07 UTC, Adam D. Ruppe wrote:
> > On Thursday, 31 October 2019 at 03:56:56 UTC, lili wrote:
> >> Hi:
> >>why writeln need GC?
>
On Thursday, 31 October 2019 at 15:11:42 UTC, Ferhat Kurtulmuş
wrote:
It would be nice if one reimplement writeln of Phobos by
bypassing gc and use a custom nogc exception as described
here*? Of course I can imagine that it would be a breaking
change in the language and requires so much work
On Thursday, 31 October 2019 at 13:46:07 UTC, Adam D. Ruppe wrote:
On Thursday, 31 October 2019 at 03:56:56 UTC, lili wrote:
Hi:
why writeln need GC?
It almost never does, it just keeps the option open in case
* it needs to throw an exception (like if stdout is closed)
* you pass it a
On Thursday, 31 October 2019 at 03:56:56 UTC, lili wrote:
Hi:
why writeln need GC?
It almost never does, it just keeps the option open in case
* it needs to throw an exception (like if stdout is closed)
* you pass it a custom type with toString that uses GC
@nogc is just super strict and
On Thursday, 31 October 2019 at 03:56:56 UTC, lili wrote:
Hi:
why writeln need GC?
I cannot answer why it needs GC but something can be implemented
like:
import core.stdc.stdio;
struct Point {
int x;
int y;
}
class Person {
string name;
uint age;
}
template
Hi:
why writeln need GC?
f (disabled) by default, but nonetheless
> allocate objects from GC memory
> * provide a function that can find (and reclaim) retained
> unreachable object graphs that contain strong reference cycles
> * the main purpose of this function is to find and report such
> instances, not to reclaim m
riate.
To help detect memory leaks from within the interpreter, I'd also
like to employ core.memory.GC in the following fashion:
* keep core.memory.GC off (disabled) by default, but nonetheless
allocate objects from GC memory
* provide a function that can find (and reclaim) retained
unreacha
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 a
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 Sunday, 21 April 2019 at 16:20:51 UTC, WebFreak001 wrote:
I'm trying to GC profile serve-d which uses a lot of fibers
potentially also across some threads and some threads doing
some dedicated work, however -profile=gc doesn't seem to work
properly. It logs `shared static this`
On 03.09.19 16:03, James Blachly wrote:
For my own learning, why was a unittest to ensure no GC added to sformat
instead of a @nogc annotation?
`sformat` uses the GC less now, but it's not @nogc. It can still throw
GC-allocated exceptions, e.g. when the arguments don't match
On 8/31/19 5:12 PM, ag0aep6g wrote:
I've made a pull request to get rid of those allocations:
https://github.com/dlang/phobos/pull/7163
Wonderful!
For my own learning, why was a unittest to ensure no GC added to sformat
instead of a @nogc annotation?
On Saturday, 31 August 2019 at 21:12:32 UTC, ag0aep6g wrote:
I've made a pull request to get rid of those allocations:
https://github.com/dlang/phobos/pull/7163
Thanks for the responses, very cool seeing these updates happen
so fluidly.
On Saturday, 31 August 2019 at 21:12:32 UTC, ag0aep6g wrote:
I've made a pull request to get rid of those allocations:
https://github.com/dlang/phobos/pull/7163
Merged.
On 31.08.19 14:07, cc wrote:
I'm guessing it's allocating a string first to write the contents
of the array and then inserting that string into the buffer I supplied.
Is there no way to have it skip this step and just write each element
(plus the joining punctuation, etc) directly into the buf
On Saturday, 31 August 2019 at 12:07:56 UTC, cc wrote:
And what, if anything, can I do to avoid it?
import core.stdc.stdio : printf;
There are no @nogc versions of the Phobos write* and format
functions.
And what, if anything, can I do to avoid it?
string[] arr = ["abcd", "efgh", "ijkl"];
char[4096] buf;
char[] res;
writeln(GC.stats);
res = sformat(buf, "%s", arr);
assert(res.ptr == buf.ptr);
writeln(res);
writeln(GC.stats);
On Wednesday, 26 June 2019 at 15:56:06 UTC, lili wrote:
Hi Guys:
I look for the GC source code in /usr/include/dmd dir,
unfortunately not find.
https://github.com/dlang/druntime/blob/master/src/gc/impl/conservative/gc.d
Hi Guys:
I look for the GC source code in /usr/include/dmd dir,
unfortunately not find.
I have written an DLL in D which gets used by an application
(written in C)
When the C code tries to deallocate/close the DLL, the C
application freezes and/or leaks memory.
My profiling using AMD µProf tells me that the D DLL never gets
closed, my guess is that the D GC never deallocates
On 12/06/2019 11:40 AM, Rémy Mouëza wrote:
If I recall correctly, there is (or was) also a precise GC in the work,
but I currently don't have any links to it.
Its already in.
Its a modification on the conservative GC to make it more efficient.
https://github.com/dlang/druntime/blob/m
On Tuesday, 11 June 2019 at 18:20:59 UTC, KnightMare wrote:
please write some explanation about subj.
- what exactly it scans?
- why it scan data-segment?
https://issues.dlang.org/show_bug.cgi?id=15723
https://issues.dlang.org/show_bug.cgi?id=19947
precise GC doesn't help with issues.
-
please write some explanation about subj.
- what exactly it scans?
- why it scan data-segment?
https://issues.dlang.org/show_bug.cgi?id=15723
https://issues.dlang.org/show_bug.cgi?id=19947
precise GC doesn't help with issues.
- maybe add new type like gcpointer or something (making word
&qu
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 the
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 h
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 --buil
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
Shou
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
. How can I
keep things on the stack between these two functions?
How is 3 done? Is this only useful for static variables?
I'll try to describe rules 2 and 3 as simply as possible: As
long as you can access the pointer to gc allocated memory in D
it will not be freed.
If you don'
?
How is 3 done? Is this only useful for static variables?
I'll try to describe rules 2 and 3 as simply as possible: As long
as you can access the pointer to gc allocated memory in D it will
not be freed.
So whether that pointer lives on the stack:
int* foo() {
return new int;
}
The D docs for interfacing with C state:
If pointers to D garbage collector allocated memory are passed to C
functions, it's critical to ensure that that memory will not be
collected by the garbage collector before the C function is done with
it. This is accomplished by:
1. Making a copy of
I'm trying to GC profile serve-d which uses a lot of fibers
potentially also across some threads and some threads doing some
dedicated work, however -profile=gc doesn't seem to work
properly. It logs `shared static this` calls and some methods,
however none of the actual stuff is in
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
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
> &
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 Adam po
On Monday, 4 March 2019 at 10:38:29 UTC, 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?
Well, conservative GC in general might, but D's GC would NOT.
D&
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 memor
byte[] snappyCompress(in byte[] plaintext) {
import deimos.snappy.snappy;
size_t output_length =
snappy_max_compressed_length(plaintext.length);
byte[] output = new byte[output_length];
if(snappy_compress(cast(char*)plaintext.ptr, plaintext.length,
cast(char*)output.ptr, &outp
/deallocator which will result in
memory corruption or just crash. I mean you definitely need to
remove that root and free() when you're done with it at some
point later.
Also fromStringz() may internally do implicit GC copy, inspect
its source, if it just appends to an array or some
Y_OK) {
string ret = (cast(string) fromStringz(output)).clone();
// < do something magical here
return ret;
}
assert(0);
}
```
How can I get the GC to automatically garbage collect the
`output` malloc call by tracking the returned `ret` re
On Thursday, 28 February 2019 at 04:26:47 UTC, Sam Johnson wrote:
Update: it seems that all I need to do is GC.addRoot(output);
and memory leak goes away. I think I have answered my own
question.
That shouldn't have any effect at all. GC.addRoot makes the GC
consider that pointer to a
On Thursday, 28 February 2019 at 03:33:25 UTC, Sam Johnson wrote:
How can I get the GC to automatically garbage collect the
`output` malloc call by tracking the returned `ret` reference?
If you want it GC managed, just GC allocate it instead of
mallocing it.
char *output = cast(char
hough note that while it would copy it into a GC array, it would
leave the original - you'd still want to free() that.
On Thursday, 28 February 2019 at 03:35:45 UTC, Sam Johnson wrote:
On Thursday, 28 February 2019 at 03:33:25 UTC, Sam Johnson
wrote:
[...]
Ignore the `.clone()` call -- that wasn't supposed to be here
-- I thought maybe string.clone() might exist but it turns out
it does not.
Update: it see
On Thursday, 28 February 2019 at 03:33:25 UTC, Sam Johnson wrote:
```
string snappyCompress(const string plaintext) {
import deimos.snappy.snappy : snappy_compress,
snappy_max_compressed_length, SNAPPY_OK;
import core.stdc.stdlib : malloc, free;
import std.string : fromStringz,
lone();
// < do something magical here
return ret;
}
assert(0);
}
```
How can I get the GC to automatically garbage collect the
`output` malloc call by tracking the returned `ret` reference? Or
is this already managed by the gc because I cast to a `string`?
On Friday, 25 January 2019 at 13:39:53 UTC, Radu wrote:
On Friday, 25 January 2019 at 13:33:25 UTC, Alex wrote:
I'm experimenting with GC, and reading
https://dlang.org/spec/garbage.html#gc_config
There is an option setting possible via
´´´
extern(C) __gshared string[] rt_options = [ &
On Friday, 25 January 2019 at 13:33:25 UTC, Alex wrote:
I'm experimenting with GC, and reading
https://dlang.org/spec/garbage.html#gc_config
There is an option setting possible via
´´´
extern(C) __gshared string[] rt_options = [ "gcopt=gc:precise"
];
//gc:conservative
I'm experimenting with GC, and reading
https://dlang.org/spec/garbage.html#gc_config
There is an option setting possible via
´´´
extern(C) __gshared string[] rt_options = [ "gcopt=gc:precise" ];
//gc:conservative|precise|manual
´´´
conservative and manual seem to work, whil
On 12/13/18 9:06 AM, Per Nordlöw wrote:
On Thursday, 13 December 2018 at 13:46:47 UTC, Steven Schveighoffer wrote:
If you use loweredExpr as a key in a builtin AA, then you need to make
it a heap allocation, because the GC cleans up AAs.
I only need it for lookup not for storage.
I guess
On Thursday, 13 December 2018 at 13:46:47 UTC, Steven
Schveighoffer wrote:
If you use loweredExpr as a key in a builtin AA, then you need
to make it a heap allocation, because the GC cleans up AAs.
-Steve
I only need it for lookup not for storage.
On 12/13/18 4:38 AM, Per Nordlöw wrote:
How do I turn the GC-allocation in toLower() to a scoped heap allocation
together with toLowerInPlace() in
void f(const scope const(char)[] expr)
{
import std.uni : toLower;
loweredExpr = toLower(expr); // temporary
// use loweredExpr as
How do I turn the GC-allocation in toLower() to a scoped heap
allocation together with toLowerInPlace() in
void f(const scope const(char)[] expr)
{
import std.uni : toLower;
loweredExpr = toLower(expr); // temporary
// use loweredExpr as key in hash table
}
when `loweredExpr` is
On Tuesday, 16 October 2018 at 09:38:44 UTC, John Burton wrote:
The information I have found indicates that it runs to free
memory when the system runs out of memory to allocate.
No, that is incorrect. By default, here's what's happening:
1) At startup (or first 'new'
On Tuesday, 16 October 2018 at 09:38:44 UTC, John Burton wrote:
Is there any documentation or information about the specifics
of the garbage collector?
The information I have found indicates that it runs to free
memory when the system runs out of memory to allocate. But will
this try to use a
It is based upon how much is currently free and is not configurable.
The GC of course doesn't just use all the system resources that would be
stupid. It will collect long before that either when you tell it to
(core.memory GC.collect) or when you do an allocation and it is enabled.
GC
Is there any documentation or information about the specifics of
the garbage collector?
The information I have found indicates that it runs to free
memory when the system runs out of memory to allocate. But will
this try to use all the system memory or some other amount before
trying to garba
On Monday, 8 October 2018 at 11:19:40 UTC, Per Nordlöw wrote:
And how this is related to the trait `hasElaborateConstructor`
for both `classes` and `structs`.
There's no such trait as far as I'm aware. If there were, it'd
likely be checking for the presence of a '__ctor' member. Thing
is, it
On Monday, 8 October 2018 at 11:19:40 UTC, Per Nordlöw wrote:
I want to understand how calls to `new` for classes
see _d_newclass
and structs are lowered by the compiler and druntime to a
GC-allocation (specifically how the `ba`-argument bits are
determined) followed by an initialization
I want to understand how calls to `new` for classes and structs
are lowered by the compiler and druntime to a GC-allocation
(specifically how the `ba`-argument bits are determined) followed
by an initialization using default constructor or via a
user-defined constructor called using arguments
On Friday, 5 October 2018 at 20:41:15 UTC, Sjoerd Nijboer wrote:
On Friday, 5 October 2018 at 14:55:04 UTC, Dennis wrote:
On Friday, 5 October 2018 at 10:03:35 UTC, Kagamin wrote:
GC allocations are 16 bytes aligned.
Is that an implementation detail or well-defined behavior?
The
501 - 600 of 1697 matches
Mail list logo
