www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - System level language, GC, allocation and typeinfo

reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
The terms "system level programming" and "garbage collection" are 
mutually exclusive, but I see the value in GC. However, I cannot 
really come up with a single situation where I don't know what 
kind of allocator I have used when accessing a pointer.

I think it makes a lot of sense to think in the direction of the 
post of Etienne and have allocator based pointer types. With a 
template heavy coding style it becomes less problematic than in a 
language like C. If you go templates all the way. That could 
reduce the amount of scanned memory significantly. Basically I 
think a system level language should have at least 
owned/borrowed, ref counted and gc-pointer types.

I also wonder how often you actually have a need to discriminate 
between more than 255 classes. It seems to me that with whole 
program compilation you could often just use a single byte for 
type info and a switch table for virtual functions. That would 
leave a lot more room for optimization.

When it comes to allocators I am more likely to use a factory for 
creating objects from my own allocator than pooling different 
types in a generic allocator. Except maybe for regions that are 
to be released at once, but I don't use that much. So I wonder if 
it is better to rather spend the effort on partial 
pre-initialization as an optimization for class specific 
factories than trying to be overly generic. By partial 
pre-initialization I mean that you reset used fields when an 
object is freed, thus you don't need to reinitialize vtable 
pointers and avoid calling constructors upon allocation (the 
objects are pre-constructed). Ideally you push object 
construction to time periods where the CPU is idle.

With a performance mindset…
May 27 2014
next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-27 9:06 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 I think it makes a lot of sense to think in the direction of the post of
 Etienne and have allocator based pointer types. With a template heavy
 coding style it becomes less problematic than in a language like C. If
 you go templates all the way. That could reduce the amount of scanned
 memory significantly. Basically I think a system level language should
 have at least owned/borrowed, ref counted and gc-pointer types.


I agree about this.

The GC could be optimized under x86_64, with 18,446,744,073,709,551,615 
possible values you don't exactly have any computers with 18 exabytes 
(18,000 petabytes) of memory. This is a lot of wasted space that could 
be used to make the GC lookups at O(1) speed with parallel collection.
May 27 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 27 May 2014 at 17:08:04 UTC, Etienne wrote:

 The GC could be optimized under x86_64, with 
 18,446,744,073,709,551,615 possible values you don't exactly 
 have any computers with 18 exabytes (18,000 petabytes) of 
 memory. This is a lot of wasted space that could be used to 
 make the GC lookups at O(1) speed with parallel collection


That is probably true. If you also limit GC to class types and 
ban internal pointers you probably could get a decent speedup.

Another optimization is to make sure that all GC pointers are 
clustered on the same cacheline, for objects with inheritance 
this is a challenge. An unorthodox solution would be to place all 
gc pointers at a negative offset in the object instance. I 
believe a single cacheline can fit 8 pointers, so careful 
clustering could probably cut the amount of scanned memory by a 
significant amount. 50%?
May 27 2014
prev sibling parent reply "MachMit" <MachMitMemory nowhere.cz> writes:
On Tuesday, 27 May 2014 at 13:06:10 UTC, Ola Fosheim Grøstad 
wrote:

 ...However, I cannot really come up with a single situation 
 where I don't know what kind of allocator I have used when 
 accessing a pointer....


Heap allocation in D is up to the user. Can you imagine something 
like http://sourceforge.net/projects/fastmm/ in D ? It's a (sorry 
for being an arsh) fuckin good memory manager...It's for user or 
RT allocations, it detects leaks, etc...It should be a source of 
inspiration for the top-notch D guys...
May 27 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/27/14, 7:59 AM, MachMit wrote:

 On Tuesday, 27 May 2014 at 13:06:10 UTC, Ola Fosheim Grøstad wrote:

 ...However, I cannot really come up with a single situation where I
 don't know what kind of allocator I have used when accessing a
 pointer....


 Heap allocation in D is up to the user. Can you imagine something like
 http://sourceforge.net/projects/fastmm/ in D ? It's a (sorry for being
 an arsh) fuckin good memory manager...It's for user or RT allocations,
 it detects leaks, etc...It should be a source of inspiration for the
 top-notch D guys...


Is there a white paper available for FastMM? Couldn't find any. -- Andrei
May 27 2014
next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 27 May 2014 at 18:19:14 UTC, Andrei Alexandrescu 
wrote:

 On 5/27/14, 7:59 AM, MachMit wrote:

 On Tuesday, 27 May 2014 at 13:06:10 UTC, Ola Fosheim Grøstad 
 wrote:

 ...However, I cannot really come up with a single situation 
 where I
 don't know what kind of allocator I have used when accessing a
 pointer....


 Heap allocation in D is up to the user. Can you imagine 
 something like
 http://sourceforge.net/projects/fastmm/ in D ? It's a (sorry 
 for being
 an arsh) fuckin good memory manager...It's for user or RT 
 allocations,
 it detects leaks, etc...It should be a source of inspiration 
 for the
 top-notch D guys...


 Is there a white paper available for FastMM? Couldn't find any. 
 -- Andrei


I Googled a little and found this, but nothing with larger scale: 


-Wyatt
May 27 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 27 May 2014 at 18:19:14 UTC, Andrei Alexandrescu 
wrote:

 Is there a white paper available for FastMM? Couldn't find any.


http://sourceforge.net/p/fastmm/code/HEAD/tree/FastMM4_Readme.txt
May 27 2014
prev sibling parent reply "MachMit" <MachMit stillnowhere.uk> writes:
On Tuesday, 27 May 2014 at 18:19:14 UTC, Andrei Alexandrescu 
wrote:

 On 5/27/14, 7:59 AM, MachMit wrote:

 On Tuesday, 27 May 2014 at 13:06:10 UTC, Ola Fosheim Grøstad 
 wrote:

 ...However, I cannot really come up with a single situation 
 where I
 don't know what kind of allocator I have used when accessing a
 pointer....


 Heap allocation in D is up to the user. Can you imagine 
 something like
 http://sourceforge.net/projects/fastmm/ in D ? It's a (sorry 
 for being
 an arsh) fuckin good memory manager...It's for user or RT 
 allocations,
 it detects leaks, etc...It should be a source of inspiration 
 for the
 top-notch D guys...


 Is there a white paper available for FastMM? Couldn't find any. 
 -- Andrei


The source file is documented IIRC. It could be a source of 
inspiration for the allocators (There is something about that in 
D you've introduced a few monthes ago, I think...), or maybe a 
branch/sub-set, GC-free, version of D arrays and classes.

But it was mainly written for the previous-decade delphi.(D7 to 
D2009), the point is it contains some optimized version of memcpy 
and memmove (inline asm partially comming from the fastcode 
project(http://fastcode.sourceforge.net/ for the x86 arch. at 
least...) But At this time the memory model was the same as D 
except that you (the programmer) were the GC...Otherwise the 
compilo was inserting some automatic cleanup code for locally 
allocated data(even when standing in the heap...)...

However something like this would be better than some user call 
to malloc/realloc...(because it internally handles the hardware 
spec...i.e
when copying: the page size, vector operations).
May 27 2014
parent "Qox" <robertw89 googlemail.com> writes:
 or maybe a branch/sub-set, GC-free, version of D arrays and 
 classes.


thumbs up for that. Everytime when i do OS-level or other 
programming in D, where i can't/won't have GC i can't have 
arrays/classes. One possibility is to hack the library but it 
either leaks memory(because you can't free it easily) or it looks 
bad on the allocation side.

what i mean with allocation side:


 Memory.setObject("FOO 42")
 foobar[] xy = a.dup;


it esentially labels the allocated memory (with .dup) so it can 
be freed later... and it just is effectivly like a non-GC'ed 
malloc...

I would like some optional parameters for the non-GC allocations 
like


 foobar[] xy = a.dup(myAllocator, 42);


(dup grabs the memory from myAllocator and passes arguments). 
Same for new like good old GC does.

Ofcourse type information and the construction of more 
complicated objects is a problem.
May 28 2014