formic enhancements revisited

[Mark S. Miller <vlad!mark>]

Date: Tue, 26 Jun 90 22:12:37 PDT
   From: xanadu!roland (Roland King)

   1) func ptr: now works like CLASS name: & FUNC name: i.e.

       $(IF FUNC ptr: SPT+) boo! $(FI) 

	   says boo! if the current function is a pointer to a type whose
       name begins with the letters "SPT".

I'm having a lot of trouble parsing this.  Do you perhaps mean "if the
current function returns a pointer to a type whose name ..."?  If so,
then I think this isn't what Rick needs.  Pseudo-constructors never
return a "pointer to a strong pointer to a type Foo" ("SPTR(Foo) *
foo()" == "SP2_Foo * foo()"), they return either a "[wimpy] pointer to
a type Foo" ("WPTR(Foo) foo()" == "Foo * foo()"), or a "strong pointer
to a type Foo" ("SPTR(Foo) foo()" == "SP2_Foo foo()").

Rick, I suspect you intended to ask for this last case, as it is
currently the only one our code uses.  However, the WPTR case will
become much more prevelant during performance engineering phase, so
you should (evetually at least) check for both.  Wimpy pointers (WPTR)
are cheaper than strong pointers mostly because they can be loaded
into registers & have fancy compiler optimizations applied to them.
Strong pointers should become approximately as efficient as naive
non-register "*" pointers (once inlines work).

The penalty is that a wimpy pointer doesn't protect the object it
points to against garbage collection, and suffers a resulting dangling
reference danger as a result.  The reason we bother to say "WPTR(Foo)"
and have it expand to "Foo *" (as opposed to just saying "Foo *" in
the first place) is to be able to check for dangling reference bugs.
The rule is "you may only wimpily point at a Heaper that you know to
not have been garbage collected for some reason" (such as awareness of
a strong pointer elsewhere to the object).  When can a
pseudo-constructor be in this position?

Many of our psuedo-constructors (such as "integerSpace()") return a
pointer to a single reused global instance which was created at
dynamic initialization time, and held onto by a global strong pointer.
As it is a side-effect free value-based object, it is semantically
transparent whether a new one is created each time, or all "creations"
actually share the one copy.  (Once again, apologies for beating the
obvious to death.  It's how I generate for the documentation mill.)