Projects

Thu May 4 09:14:00 GMT 2000

>>>>> "Jon" == Jonathan P Olson <olson@mmsi.com> writes:

Jon> How do I get a copy of the paperwork? Can you email a copy to
Jon> sign? Who do you need to sign it? I'm CTO here at MMS, is that
Jon> OK? Who accepts patches for `gcc'? On what criteria do they
Jon> accept them?
You can see the paperwork here:
 http://gcc.gnu.org/contribute.html
I think there is some text there that explains what is going on, who
can sign, and so forth.
The gcc maintainers accept patches to gcc. You can send patches to
gcc-patches@gcc.gnu.org.
Who exactly approves patches, or why, is complicated. It depends on
which parts of gcc your patches touch. We (the gcj people) don't have
a lot of direct input into this process (i.e., Alex can't approve a
back-end patch), but we can certainly advocate for the patches and try
to see about fixing whatever problems the gcc maintainers might have.
Jon> Note, however, that somebody needs to write up the write_barrier
Jon> patterns for all the supported architectures.
I'm not too worried about that. We don't have a GC that can use this
yet! I see this more as setting the stage for later work: we know it
is a prerequisite, so why not try to get it out of the way now?
Jon> Against what version of gcc do the patches need to be made?
Current cvs would be best. These changes probably can't go on the
2.95 branch.
Jon> Is it acceptable to require GC with exception handling to
Jon> eliminate memory leaks?
For C++, almost certainly not.
Jon> 2) They allow the implementation of copying collectors.
Jon> Option 2) just isn't practical in a C or C++ environment. There
Jon> are just too many registers, unions, assembly code, etc., which
Jon> contain pointers to realistically relocate them in a copying
Jon> collector.
I think we could do this for Java and CNI code (C++ code that is
manipulating Java objects). There is a paper I have about how to
modify gcc to allow this.
Jon> This write-barrier implementation merely invokes a RTL pattern in
Jon> the compiler back end whenever the compiler writes to a pointer.
Jon> This RTL pattern is free to do anything, but it should be very
Jon> fast.
Cool, that's what I wanted to know. Thanks.
Jon> Replacing the write barrier implementation is merely linking with
Jon> a library containing the desired write barrier code.
I think ultimately we'd like to find an approach that will let us
inline the write barriers. Perhaps we can find a way to load selected
bits of RTL from a file. We don't have to solve this right away.
Jon> Regarding precise and copying GCs, see my comments above. In a C
Jon> or C++ environment I just don't see how they're justifyable.
I think they still make sense. We don't have to solve the whole
problem, because in general we aren't going to be allocated unions or
weird C structures using the GC. We only have to solve the part of
the problem relating to GCable objects -- i.e., Java objects.
Tom