ttwang@polyslo.CalPoly.EDU (Thomas Wang) (09/09/89)
I have discovered an interesting issue during the implementation of my
garbage collection project.
There does not appear to be a portable way to copy an object from one
memory location to another. The operator '=' might be overloaded, so
I cannot depend on it for copying.
If I can copy an object, then I can compact the memory when doing garbage
collection. Right now, heap fragmentation is a possibility.
On the other hand, the C language has always the problem of heap fragmentation,
and yet it's the most popular language!
-Thomas Wang (I've always wanted a 1/1 scale model of Ayukawa Madoka
lying in my room.)
ttwang@polyslo.calpoly.edubeshers@cs.cs.columbia.edu (Clifford Beshers) (09/09/89)
How about bcopy(sizeof(object))? -- ----------------------------------------------- Cliff Beshers Columbia University Computer Science Department beshers@cs.columbia.edu
shopiro@alice.UUCP (Jonathan Shopiro) (09/10/89)
In article <14265@polyslo.CalPoly.EDU>, ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes: > I have discovered an interesting issue during the implementation of my > garbage collection project. > > There does not appear to be a portable way to copy an object from one > memory location to another. The operator '=' might be overloaded, so > I cannot depend on it for copying. > The constructor X::X(const X&) has a special position in the language in that it is used for copying objects. If X::X(const X&) is not declared, but X::X(X&) is, then the latter becomes the copy-constructor. The copy- constructor is invoked when you initialize an X from another X, most commonly when passing an X to a function, or returning an X from a function. To move an object, you would probably use the copy-constructor with the placement allocation syntax, as in the following example: void move(const X& obj) // obj is the object to be moved { void* vp = <computation>; // now vp contains the address where the copy of obj // is to go new (vp) X(obj); // invokes the copy-constructor obj.X::~X(); // invoke the destructor (without // de-allocating storage) on the old copy } As it said in my old Sail manual, you had better know what you are doing, or be a good sport. This is not for the faint of heart. In a subsequent article, Cliff Beshers suggests using memcpy to copy objects. This will often work, but some objects do not permit bitwise copying, and they will trip you up. The compiler will synthesize a copy-constructor if you don't supply any constructors for your class, and if bitwise copying is appropriate for your class, that's what it will come up with. So use the copy-constructor, and you get the best of both worlds. -- Jonathan Shopiro AT&T Bell Laboratories, Warren, NJ 07060-0908 research!shopiro (201) 580-4229
dog@cbnewsl.ATT.COM (edward.n.schiebel) (09/11/89)
From article <14265@polyslo.CalPoly.EDU>, by ttwang@polyslo.CalPoly.EDU (Thomas Wang): > ... > There does not appear to be a portable way to copy an object from one > memory location to another. The operator '=' might be overloaded, so > I cannot depend on it for copying. Would the form of new: new (some_address) X(an_x); which places the new X, in this case initialized using the X(const X&) constructor, at the memory location some_address work? Ed Schiebel AT&T Bell Laboratories dog@vilya.att.com
ark@alice.UUCP (Andrew Koenig) (09/11/89)
In article <14265@polyslo.CalPoly.EDU>, ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes: > There does not appear to be a portable way to copy an object from one > memory location to another. The operator '=' might be overloaded, so > I cannot depend on it for copying. Copying an object to a new location presumably means creating a new object that is a copy of the old one and then deleting the old object. To copy an object of class T, use T(const T&); if that doesn't work, nothing will. To determine the locations and handle the memory management, use the memory management stuff in cfront 2.0. For example, if `oldloc' and `newloc' point at the old and new locations, you want to write something like this: void* operator new(size_t, void* p) { return p; } new(newloc) T (*oldloc); oldloc->T::~T(); Now newloc points at a copy of the object and oldloc points at garbage that should be freed. None of this works, of course, if the old and new objects overlap. -- --Andrew Koenig ark@europa.att.com
vaughan@mcc.com (Paul Vaughan) (09/11/89)
In article <14265@polyslo.CalPoly.EDU>, ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes: > I have discovered an interesting issue during the implementation of my > garbage collection project. > > There does not appear to be a portable way to copy an object from one > memory location to another. The operator '=' might be overloaded, so > I cannot depend on it for copying. > The constructor X::X(const X&) has a special position in the language in that it is used for copying objects. If X::X(const X&) is not declared, but X::X(X&) is, then the latter becomes the copy-constructor. The copy- constructor is invoked when you initialize an X from another X, most commonly when passing an X to a function, or returning an X from a function. To move an object, you would probably use the copy-constructor with the placement allocation syntax, as in the following example: void move(const X& obj) // obj is the object to be moved { void* vp = <computation>; // now vp contains the address where the copy of obj // is to go new (vp) X(obj); // invokes the copy-constructor obj.X::~X(); // invoke the destructor (without // de-allocating storage) on the old copy } I have a couple of problems with this approach, the first is trivial, the second arises from my confusion over what X::X(const X&) definitions are supposed to do. First, wouldn't the move function need to be X::move(const X& x) instead of a normal function? Second, from Lippman's discussion on page 250, it appears that it is reasonable to define copy constructors to copy the objects to which the X object has pointers, especially when those objects are (conceptually but not in actual class structure) considered to be components of the X. In Lippman's example, a String class has a copy constructor that does a strcpy on its char* str. Is this what is desired when moving objects? To move such a String object, it is really only necessary to create a String object in a different place with the same char* str (and of course be sure that any references to the String are corrected). It isn't necessary to copy the array of characters. On the other hand, it might make sense to go ahead and copy the characters in order to improve locality in a GC application. At one point I was considering creating a system that could relocate objects mostly as a way of changing the class of the object. I had thought I might overload the -> operator to implement a forwarding pointer scheme (sort of like a Lisp implementation) and then just move objects at will. This would let me change the class of an object easily, whether or not the new object required more space. I decided I didn't know how to that and put it off indefinitely (that is, I blew it off :-). One of my problems was how to copy objects and whether it made sense to copy their components as the X::X(const X&) would do. Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
bright@Data-IO.COM (Walter Bright) (09/12/89)
In article <14265@polyslo.CalPoly.EDU> ttwang@polyslo.CalPoly.EDU (Thomas Wang) writes:
<There does not appear to be a portable way to copy an object from one
<memory location to another. The operator '=' might be overloaded, so
<I cannot depend on it for copying.
Try:
memcpy(to,from,sizeof(object));ttwang@polyslo.CalPoly.EDU (Thomas Wang) (09/12/89)
It is my impression that memcpy() work OK if the following things do not
happen:
1) The object to be moved does not contain physical pointers to itself.
2) The object to be moved does not contain physical pointers to other
objects which could be moved.
These two requirements can be met in principle. However there are nastier
problems. If you are in the middle of an object's member function, and
that object gets moved, then 'this' will be pointing to the wrong place.
To solve this problem, you would either have to lock an object, or have
the ability to modify the value of 'this' to point to the correct place.
It does seem that 'copying garbage collection' is too much a hassle to
implement in C++. I think I will stick to not moving any objects.
-Thomas Wang (Ranma no baka!
- Ranma 1/2 )
ttwang@polyslo.calpoly.edu