www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Improve reability of GC on win64

reply Temtaime <temtaime gmail.com> writes:
Hi !
I have an app with large amount of math, so there's lot of arrays 
with floats.
I found that sometimes my app starts to eat memory and then it 
crash.

The problem i think is false pointers. For example i have a 
struct with pointers and static array of floats. GC marks entire 
struct as containing pointers. And when some data in the array 
starts to point to valid memory region, gc won't release that 
memory.

Also i build my app as 64 bit. I found that gc allocates memory 
using
https://github.com/D-Programming-Language/druntime/blob/1f957372e5dadb92ab1d621d68232dbf8a2dbccf/src/gc/os.d#L64

And all the addresses if i print them are below 4G. So only low 
32 bits of 64 bit address are used.

One can give preferred address to VirtualAlloc and make it > 4G.
I changed implementation of os_mem_map to something like:

ulong addr = 1 << 40;

while(true) {
if(auto p = VirtualAlloc(cast(void *)addr, nbytes, MEM_RESERVE | 
MEM_COMMIT,
                 PAGE_READWRITE)) return p;
addr += nbytes;
}

And my problem with growing memory had gone.
I think we should alter implementation of os_mem_map to allocate 
using addresses > 4G, so high bits won't be zeros and it'll help 
with false pointer.

I think we should use some random function here. Maybe rdtsc ? Or 
maybe there's other opinions ?

Thanks.
Mar 24 2016
parent reply Adam Wilson <flyboynw gmail.com> writes:
On 3/24/2016 11:25, Temtaime wrote:

 Hi !
 I have an app with large amount of math, so there's lot of arrays with
 floats.
 I found that sometimes my app starts to eat memory and then it crash.

 The problem i think is false pointers. For example i have a struct with
 pointers and static array of floats. GC marks entire struct as
 containing pointers. And when some data in the array starts to point to
 valid memory region, gc won't release that memory.

 Also i build my app as 64 bit. I found that gc allocates memory using
 https://github.com/D-Programming-Language/druntime/blob/1f957372e5dadb92ab1d621d68232dbf8a2dbccf/src/gc/os.d#L64


 And all the addresses if i print them are below 4G. So only low 32 bits
 of 64 bit address are used.

 One can give preferred address to VirtualAlloc and make it > 4G.
 I changed implementation of os_mem_map to something like:

 ulong addr = 1 << 40;

 while(true) {
 if(auto p = VirtualAlloc(cast(void *)addr, nbytes, MEM_RESERVE |
 MEM_COMMIT,
                  PAGE_READWRITE)) return p;
 addr += nbytes;
 }

 And my problem with growing memory had gone.
 I think we should alter implementation of os_mem_map to allocate using
 addresses > 4G, so high bits won't be zeros and it'll help with false
 pointer.

 I think we should use some random function here. Maybe rdtsc ? Or maybe
 there's other opinions ?

 Thanks.


That is an interesting hack, but I would think it is rather brittle.

Their are two long-term solutions that will get you want you want. The 
first is to avoid the GC altogether and manually allocate everything. 
The second is a Precise GC. And while it's impossible to be 100% precise 
GC given that we have unions and C-compatibility, for your use case I 
imagine the precision would give you most of what you need.

Interestingly enough, there is a GSoC candidate this year that is 
proposing a project that would make the D GC precise.
Mar 24 2016
next sibling parent reply Temtaime <temtaime gmail.com> writes:
On Thursday, 24 March 2016 at 18:58:56 UTC, Adam Wilson wrote:

 On 3/24/2016 11:25, Temtaime wrote:

 [...]


 That is an interesting hack, but I would think it is rather 
 brittle.

 Their are two long-term solutions that will get you want you 
 want. The first is to avoid the GC altogether and manually 
 allocate everything. The second is a Precise GC. And while it's 
 impossible to be 100% precise GC given that we have unions and 
 C-compatibility, for your use case I imagine the precision 
 would give you most of what you need.

 Interestingly enough, there is a GSoC candidate this year that 
 is proposing a project that would make the D GC precise.


Yes, i think precise gc can solve all the problems and it'll 
great.
And what's a problem with unions by the way ? By specs, currently 
it's forbidden to have union with pointers and value types.
Mar 24 2016
parent reply Iakh <iaktakh gmail.com> writes:
On Thursday, 24 March 2016 at 19:30:46 UTC, Temtaime wrote:


 And what's a problem with unions by the way ? By specs, 
 currently it's forbidden to have union with pointers and value 
 types.


It's forbidden in  safe
Mar 24 2016
parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 25 March 2016 at 05:46:04 UTC, Iakh wrote:

 On Thursday, 24 March 2016 at 19:30:46 UTC, Temtaime wrote:


 And what's a problem with unions by the way ? By specs, 
 currently it's forbidden to have union with pointers and value 
 types.


 It's forbidden in  safe


I actually asked about this in the GSOC GC thread. I was thinking 
you could make the GC more precise in  safe code because of that 
restriction.
Mar 25 2016
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Thursday, 24 March 2016 at 18:58:56 UTC, Adam Wilson wrote:

 [snip]

 Interestingly enough, there is a GSoC candidate this year that 
 is proposing a project that would make the D GC precise.


There was already a GSOC project to make the GC precise by 
Antti-Ville Tuuainen back in 2012. Rainer expanded upon it[1] and 
gave a talk about it at DConf 2013[2].

I'm not sure why it never went anywhere.

In any case, I don't think a precise GC is a good GSOC project 
since most of the work has already been done. I feel like a GC 
focused GSOC project should be more ambitious than merely tying 
up the loose ends of the existing precise GC work.

1. https://github.com/rainers/druntime/tree/gcx_precise
2. http://dconf.org/2013/talks/schuetze.pdf
Mar 24 2016
parent Adam Wilson <flyboynw gmail.com> writes:
On 3/24/2016 23:06, Brad Anderson wrote:

 On Thursday, 24 March 2016 at 18:58:56 UTC, Adam Wilson wrote:

 [snip]

 Interestingly enough, there is a GSoC candidate this year that is
 proposing a project that would make the D GC precise.


 There was already a GSOC project to make the GC precise by Antti-Ville
 Tuuainen back in 2012. Rainer expanded upon it[1] and gave a talk about
 it at DConf 2013[2].

 I'm not sure why it never went anywhere.

 In any case, I don't think a precise GC is a good GSOC project since
 most of the work has already been done. I feel like a GC focused GSOC
 project should be more ambitious than merely tying up the loose ends of
 the existing precise GC work.

 1. https://github.com/rainers/druntime/tree/gcx_precise
 2. http://dconf.org/2013/talks/schuetze.pdf


(DISCLOSURE: I am a Mentor for GSoC and worked with the student on the 
proposal in question.)

Well, it's not quite that simple. First, the Precise GC is two years 
bit-rotten according to Rainer. So it needs to be pulled up to current D 
spec.

Second, there was never a well engineered integration solution, which is 
a major part of the reason that it never got accepted in the first 
place. The GSoC project proposal calls for work to be done on making the 
new GC a command-line switch so you can pick the right GC for your 
project. This will also enable a faster iteration cycle on the new GC by 
making it optional so we can try new algorithms and experiment without 
making the experiments mandatory for everyone.

Third, there were suggestions on the forum about how to make the 
allocation low-lock or lock-free and that also made it in to the proposal.

Lastly, the student is going to spend most of their time plumbing the 
bowls of the Compiler and GC looking for more ways to improve precision. 
Stack/TLS/Register scanning are going to be added or improved. Automatic 
pinning of C-style pointers and concurrent scanning were also mentioned 
in the forums as useful as well, but it is unlikely the student will 
have the time to get to those items.

So yes, Rainer and Antti-Ville's work is a starting point. But the goal 
of the project is to get something that actually works into the mainline 
D releases. And that is, from an engineering standpoint, a significant 
undertaking.

While the volume of new code written might not be as high as other 
projects, the GC needs to maintain a higher level of quality than the 
average Phobos submission due to the fact that the GC is fundamental to 
D. Meeting that high quality bar is going to be a significant 
undertaking on it's own, and work will probably progress a little slower 
than a Phobos module would in order to maintain that quality.
Mar 25 2016