Khimenko Victor wrote:
7-Mar-00 18:57 you wrote:
One of the things that steers me away from Borland Pascal is its lack of a runtime garbage collector.
Does GNU Pascal have a runtime garbage collector?
No. To All: perhaps something can be done here ? Boehm's GC will work just fine with GPC in simple cases but if you'll try to use strings or some other complex structures it'll be less great :-/ In C++ it's done with "class's new" but I know of no such mechanism in GPC ... At least low-level allocation functions needed (now many bytes GC should allocate to put this structure there? how really put it there?)...
I haven't used it yet, but I don't see the problem. AFAIUI, Boehm's GC http://reality.sgi.com/boehm/gc.html provides a drop-in replacement for malloc() (and a dummy replacement for free()). Since GPC's memory management uses malloc()/free() by default (it can be overwritten on the Pascal level, but this doesn't seem necessary here), it should work, however simple or complex the structures (malloc() doesn't care, it just gets a number of bytes and allocates that much memory).
Frank
8-Mar-00 21:36 you wrote:
Khimenko Victor wrote:
7-Mar-00 18:57 you wrote:
One of the things that steers me away from Borland Pascal is its lack of a runtime garbage collector.
Does GNU Pascal have a runtime garbage collector?
No. To All: perhaps something can be done here ? Boehm's GC will work just fine with GPC in simple cases but if you'll try to use strings or some other complex structures it'll be less great :-/ In C++ it's done with "class's new" but I know of no such mechanism in GPC ... At least low-level allocation functions needed (now many bytes GC should allocate to put this structure there? how really put it there?)...
I haven't used it yet, but I don't see the problem. AFAIUI, Boehm's GC http://reality.sgi.com/boehm/gc.html provides a drop-in replacement for malloc() (and a dummy replacement for free()). Since GPC's memory management uses malloc()/free() by default (it can be overwritten on the Pascal level, but this doesn't seem necessary here), it should work, however simple or complex the structures (malloc() doesn't care, it just gets a number of bytes and allocates that much memory).
This is NOT what you usually want. GC ALWAYS has penatly over "normal" malloc/free way. Yes, there are benefits as well but when you are using third-party library where malloc/free already used then with GC's replacement you'll get slowdown and nothing more. In case of C it's all simple: just use malloc/free and gc_alloc as desired. In case of C++ overloaded new can be used for this purpose. In case of GPC you can have GC-enabled new (with GC's malloc) or non GC-enabled new bot not both :-/ You can not just use gc_alloc(sizeof(record)) since if record has embedded strings or files you need to initialize it first (and if record has virtual part then new can allocate less then gc_alloc(sizeof(record)) -- or is this Pascal's feature not implemented yet?). So the question is: is it possible to use another allocator (and deallocator) in GPC's new ? Something akin to field:=new(malloc,OldNormalNonGcClass); ptr:=new(gc_alloc,TestClass); dispose(free,field);
Something like this was discussed when shred memory allocation problem was discussed but I can not find it :-/
Khimenko Victor wrote:
[...] In case of GPC you can have GC-enabled new (with GC's malloc) or non GC-enabled new bot not both :-/ You can not just use gc_alloc(sizeof(record)) since if record has embedded strings or files you need to initialize it first [...]
That's not a problem since the GC-enabled malloc() can hook into GPC's run-time library where it is used instead of the usual malloc(). Initialization is done afterwards.
(and if record has virtual part then new can allocate less then gc_alloc(sizeof(record)) -- or is this Pascal's feature not implemented yet?).
It's not implemented yet, but if it were, it would not be a problem either.
Peter
9-Mar-00 01:01 you wrote:
Khimenko Victor wrote:
[...] In case of GPC you can have GC-enabled new (with GC's malloc) or non GC-enabled new bot not both :-/ You can not just use gc_alloc(sizeof(record)) since if record has embedded strings or files you need to initialize it first [...]
That's not a problem since the GC-enabled malloc() can hook into GPC's run-time library where it is used instead of the usual malloc(). Initialization is done afterwards.
Arrrggghhh. Looks like I can not understood something. Let's took the following "C" snippet: -- cut -- non_collectable_ptr=(struct some_struct *)malloc(sizeof(some_struct)); collectable_ptr=(struct some_struct *)GC_malloc(sizeof(some_struct)); ptrfree_ptr=(char *)GC_malloc_atomic(BUFFER_SIZE); -- cut -- here is equivalent "C++" snippet: -- cut -- non_collectable_ptr=new some_struct; collectable_ptr=new(GC) some_struct; ptrfree_ptr=new(PointerFreeGC) char[BUFFER_SIZE]; -- cut --
What's pascal equivalent ? I repeat: I can understood that if I'll replace malloc with gc_alloc globally GPC's new will work just fine. But how I can use GC and old tried malloc/free in ONE program ?
(and if record has virtual part then new can allocate less then gc_alloc(sizeof(record)) -- or is this Pascal's feature not implemented yet?).
It's not implemented yet, but if it were, it would not be a problem either.
Perhaps. If I'll be able to understood how to use GC at all (and no, NOT as replacement for normal new/free functions!).
P.S. If you are just replacing malloc with GC_alloc then you asking for troubles (nasty DoS attacks). In C/C++ you can EASILY avoid such attacks (see third line of each sample). Without such protection Boehm's GC is dangerous tool.
Khimenko Victor wrote:
non_collectable_ptr=(struct some_struct *)malloc(sizeof(some_struct)); collectable_ptr=(struct some_struct *)GC_malloc(sizeof(some_struct)); ptrfree_ptr=(char *)GC_malloc_atomic(BUFFER_SIZE);
What's the difference between GC_malloc() and GC_malloc_atomic()?
What's pascal equivalent ? I repeat: I can understood that if I'll replace malloc with gc_alloc globally GPC's new will work just fine. But how I can use GC and old tried malloc/free in ONE program ?
I'd suggest to write two procedures to flip the hook between normal allocation and using the GC. I also see that this makes problems with threads ... have to think about that ...
Peter
9-Mar-00 10:33 you wrote:
Khimenko Victor wrote:
non_collectable_ptr=(struct some_struct *)malloc(sizeof(some_struct)); collectable_ptr=(struct some_struct *)GC_malloc(sizeof(some_struct)); ptrfree_ptr=(char *)GC_malloc_atomic(BUFFER_SIZE);
What's the difference between GC_malloc() and GC_malloc_atomic()?
When you are allocating buffer with GC_alloc_atomic you are GURANTEE that in that buffer you will not store pointers. It'll speedup GC's work but what's is MUCH more important is that if content of that buffer come from outside GC can not go nuts anymore (no matter what is stored in buffer GC will not interpret is as pointer to object so malicious user can not fool GC). Yes, porbably exploit is not easy (not THAT hard also: pointer to some byte in structure is enough to make this structure non-collectable; Boehm's GC should cope with "C"!) but 1) it's not good style 2) if exploit can be prevented easily then better to to this.
What's pascal equivalent ? I repeat: I can understood that if I'll replace malloc with gc_alloc globally GPC's new will work just fine. But how I can use GC and old tried malloc/free in ONE program ?
I'd suggest to write two procedures to flip the hook between normal allocation and using the GC. I also see that this makes problems with threads ... have to think about that ...
-
Frank Heckenbach -
Khimenko Victor -
Peter Gerwinski