This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: a .NET alternative (GJC et al)




Yeah, we are talking past each other here.

What we don't need (or want to depend upon) is an extension to C or
C++ compilers that gives enough reflective data to scan the C stack
accurately.  So if you are extending the run-time system in C/C++, or
writing "foreign functions", the precise GC support comes from outside
the compiler.  It doesn't have to be "by hand" -- just portable and
orthogonal to the C/C++ compiler.

But the Java compiler knows about GC, sure.

When thinking about building a nice run-time system, I think we should
not limit our attention to just one compiler or interpreter (nor
should we try to serve every possible compiler or interpreter).

-t



   Cc: gcc@gcc.gnu.org
   X-Zippy:  Where does it go when you flush?
   Reply-To: tromey@redhat.com
   From: Tom Tromey <tromey@redhat.com>
   Date: 29 Jul 2001 14:10:50 -0600
   X-UIDL: b2012221804d0c42bc0dc2159af697ad

   >>>>> "Tom" == Tom Lord <lord@regexps.com> writes:

   [ precise GC ]

   Tom> That's one approach.  Implementing it entirely outside of the
   Tom> compiler is another.  Some of the reasons I like the idea of
   Tom> doing it outside the compiler are that will be more widely
   Tom> useful, simpler, and less of a maintenance burdon on the future.

   I assume you mean doing it by hand in the source code.
   That's fine for C and C++.  I don't see how it can work for Java.
   For compiled Java, compiler support is required.

   Tom



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]