On Saturday, 27 May 2017 at 17:57:03 UTC, Mike B Johnson wrote:
And what if one isn't interfacing to C? All pointers should be
known.
Apparently some people are (were?) working on semi-precise GC:
https://github.com/dlang/druntime/pull/1603
That still scans the stack conservatively, though.
On Saturday, 27 May 2017 at 17:57:03 UTC, Mike B Johnson wrote:
And what if one isn't interfacing to C? All pointers should be
known. You can't access memory by and int or any other
non-pointer type! Hence, when pointers are created or ints are
cast to pointers, the GC should be informed and
On Friday, 26 May 2017 at 18:19:48 UTC, H. S. Teoh wrote:
On Fri, May 26, 2017 at 06:06:42PM +, Mike B Johnson via
Digitalmars-d-learn wrote:
On Friday, 26 May 2017 at 14:05:34 UTC, ag0aep6g wrote:
> On 05/26/2017 10:15 AM, realhet wrote:
> > But hey, the GC knows that is should not search
On Fri, May 26, 2017 at 06:06:42PM +, Mike B Johnson via
Digitalmars-d-learn wrote:
> On Friday, 26 May 2017 at 14:05:34 UTC, ag0aep6g wrote:
> > On 05/26/2017 10:15 AM, realhet wrote:
> > > But hey, the GC knows that is should not search for any pointers
> > > in those large blocks. And the
On Friday, 26 May 2017 at 18:06:42 UTC, Mike B Johnson wrote:
On Friday, 26 May 2017 at 14:05:34 UTC, ag0aep6g wrote:
On 05/26/2017 10:15 AM, realhet wrote:
But hey, the GC knows that is should not search for any
pointers in those large blocks.
And the buffer is full of 0-s at the start, so
On Friday, 26 May 2017 at 14:05:34 UTC, ag0aep6g wrote:
On 05/26/2017 10:15 AM, realhet wrote:
But hey, the GC knows that is should not search for any
pointers in those large blocks.
And the buffer is full of 0-s at the start, so there can't be
any 'false pointers' in it. And I think the GC
On 05/26/2017 10:15 AM, realhet wrote:
But hey, the GC knows that is should not search for any pointers in
those large blocks.
And the buffer is full of 0-s at the start, so there can't be any 'false
pointers' in it. And I think the GC will not search in it either.
The issue is not that the
Jordan Wilson wrote:
This I think achieves the spirit of your code, but without the
memory exception:
ubyte[] st;
foreach(i; 0..2000){
writeln(i);
st.length=500_000_000; // auto = new ubyte[500_000_000];
st.length=0; // destory(st)
st.assumeSafeAppend;
//
On Friday, 26 May 2017 at 08:15:49 UTC, realhet wrote:
64bit is not a solution because I need to produce a 32bit dll,
and I also wanna use 32bit asm objs.
The total 2GB amount of memory is more than enough for the
problem.
My program have to produce 300..500 MB of continuous data
frequently.
On Friday, 26 May 2017 at 06:31:49 UTC, realhet wrote:
Hi,
I'm kinda new to the D language and I love it already. :D So
far I haven't got any serious problems but this one seems like
beyond me.
import std.stdio;
void main(){
foreach(i; 0..2000){
writeln(i);
auto st = new
On 26/05/2017 9:15 AM, realhet wrote:
Thanks for the answer!
But hey, the GC knows that is should not search for any pointers in
those large blocks.
And the buffer is full of 0-s at the start, so there can't be any 'false
pointers' in it. And I think the GC will not search in it either.
The
Thanks for the answer!
But hey, the GC knows that is should not search for any pointers
in those large blocks.
And the buffer is full of 0-s at the start, so there can't be any
'false pointers' in it. And I think the GC will not search in it
either.
The only reference to the buffer is 'st'
On Friday, May 26, 2017 06:31:49 realhet via Digitalmars-d-learn wrote:
> Hi,
>
> I'm kinda new to the D language and I love it already. :D So far
> I haven't got any serious problems but this one seems like beyond
> me.
>
> import std.stdio;
> void main(){
> foreach(i; 0..2000){
>
Hi,
I'm kinda new to the D language and I love it already. :D So far
I haven't got any serious problems but this one seems like beyond
me.
import std.stdio;
void main(){
foreach(i; 0..2000){
writeln(i);
auto st = new ubyte[500_000_000];
destroy(st); //<-this
14 matches
Mail list logo
