cni-changes documented?

Boehm, Hans hans.boehm@hp.com
Thu Mar 18 22:37:00 GMT 2004


I agree with "maybe" :-) .

Smart pointers by themselves don't let you identify all pointers into
the heap.  The program can declare all Java pointer variables in C++ this way,
and we can certainly identify Java pointers in Java code.  And you
could tell the programmer not to put Java pointers in C unions, etc.

I suspect that if you want good performance, these "smart pointers"
won't be implementable entirely as C++ source; the compiler would use them
to generate static layout information.  (I'm not sure whether the
smart pointers to implement null-pointer checks are implemented as C++
source.)

The problem is that during expression evaluation, gcc will generate
temporaries, e.g. after adding an offset to a Java pointer.  The gcc
backend would have to provide information about the location of these
temporary pointers if you wanted to be able to move objects.
I don't think you can reconstruct such information from unwind and/or
debug information.

If you don't need to move objects, you would have to ensure that the
temporary pointers don't outlive the pointer variables from which they
were derived.  This is sometimes also nontrivial, since the original
pointer variables may be dead while the derived pointer is still live.
(Even with the conservative collector, I think we have some issues there.
But with a type accurate collector, I suspect it would become noticeable,
and we'd really have to fix it.)

Most conventional JVMs provide this kind of information only at certain
"safe points", which reduces the amount of information that needs to be
transmitted to the GC.  But that's not a notion that gcc currently understands,
and the current collector can stop a thread at any point.

At least in my experience, a general problem with C++ "smart pointers"
is that they only behave 95% like pointers, and it's usually still
possible to get premature deallocation if you try, or if you try to
manually optimize too aggressively.  Thus it would be good to make sure
the "safe usage" rules are understood.

None of this is impossible.  And it's all been done in some other form.
But I think it would be a major effort to really make this robust.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Andrew Haley
> Sent: Wednesday, March 17, 2004 4:08 AM
> To: Adam Megacz
> Cc: java@gcc.gnu.org
> Subject: Re: cni-changes documented?
> 
> 
> Adam Megacz writes:
>  > 
>  > root <aph@redhat.com> writes:
>  > > This wil make no difference *at all* to anyone who has 
> an MMU that
>  > > does trap on null pointer accesses;
>  > 
>  > Ah, right.
>  > 
>  > BTW, I'm not too knowledgeable on the gory details of C++ 
> templates,
>  > but would smart pointers let us do precise GC?
> 
> I've been discussing this with Hans.  The answer is a definite
> "maybe"!  :-)
> 
> Really, it all depends on what restrictions we're prepared to put on
> the writers of CNI code.  I reckon the necessary restrictions are
> quite reasonable, but I haven't been able to persuade Hans.  So, the
> jury is out.
> 
> Andrew.
> 



More information about the Java mailing list