🚀 go-pugleaf

bgibbons@taligent.com (Bill Gibbons) wrote:
>In article <48gmat$i43@engnews1.eng.sun.com>, clamage@Eng.Sun.COM wrote:
>
>> The key point is whether you can do that during execution of a member
>> function on behalf of the original object.
>> 
>> I think the answer is no.
>
>I beg to differ.  I believe the issue of destroying an object from within
>a member's execution has been resolved, and the answer was that it's OK:
>
>    void A::f() { delete this; }  // OK

This is unfortunate, because it may force _unloading_ of cached
addresses before calling a member function. For example on the 486:

; function g() { f(); }

     LES BX, object_address ; load ES:BX with 'this' pointer
     CALL f                 ; call member function
     RET

This machine code may LOOK OK, but it ISNT. Why? Because an
interrupt may come flying in after the call to f and before the
return. The machine registers are pushed onto the stack
in the interrupt. After the interrupt has done its job
it pops the register back. WOOPS!!! A segment register
gets loaded with an invalid address. A general protection
fault ensues.

This is NOT a hyposthetical example, it happens right now
(under Borland 4.5), and it happened to a friend of mine
who had to debug someone else's code.

ES must be loaded with a valid address
at all times, 0 will do. But in general there's no way to tell
when deallocating memory whether a register contains a reference
to that memory (other than an address comparison on the segment
register in the deallocator ??).

So IF the 'this' pointer is to be cached across calls to
unknown functions, the compiler has to assume the object
is not deleted.

The argument against changing the type is similar -- IF
the virtual table pointer is to be cached in a register,
it can't be allowed to be changed until the (lexical)
end of the block of code for which it was loaded.
Otherwise the wrong offset may be used in looking up
a subsequent virtual function call or pointer
offset adjustment.

[Perhaps a test will fix this:

    LES BX, vtable1
    CALL f           ; any function
    MOV AX,ES
    CMP vtable1,AX
    JEQ label
    LES BX, vtable1 ; reload vtable pointer :-(((((
label:
]

Does the compiler _really_ have to generate this horrid code?

Note that on the 486 loading segment registers is VERY EXPENSIVE.

>Here's a somewhat more robust version of the example:
>
>  virtual void Derived::f() {
>    if (--n == 0) {
>      void *mem = dynamic_cast<void*>(this);  // start of complete object
>      this->~Derived();
>      new (mem) Base;
>    }
>  }
>
>I agree that this is pretty ugly, but I think the current working paper
>makes it well-formed.

A great pity if this is the case, a major optimisation opportunity 
appears to be lost on the most common processor.

[Perhaps I'm wrong though: it's hard to be certain there isn't
a clever way around this problem]


-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]