Sat Feb 27 02:24:00 GMT 1999
>>>>> "Jon" == Jon Olson <firstname.lastname@example.org> writes:
>> But you still need the sync_info somewhere.
Jon> Since a minority of Java objects are actually synchronized, a
Jon> hash table or sparse array might be better than wasting a pointer
Jon> per object. Really depends on how many sync'd objects you have.
The thread code in our runtime was designed with the idea of being
able to select this at build time. Right now you don't have a choice
(since the info is hard-coded into both gcc and the library), but in
theory you could change the layout without changing the thread ports
or the native part of java.lang.Thread.
It would probably only take a couple days, max, to make this change.
Jon> I've never really seen a working implementation of a truly
Jon> generational or incremental conservative GC.
On some platforms the Boehm GC is incremental. It works by playing
virtual memory tricks.
>> [ Handles ]
>> Plus you kill Java/C++ compatibility, which libjava depends on.
Jon> I'm not convinced that this is the case. It just changes gjavah
Jon> and native methods a bit.
When Per says that libjava depends on this compatibility, what he
means is that most of our native methods are written in C++ and take
advantage of the fact that a Java object has the same layout as a C++
object. That is, our C++ code makes method calls on Java objects, and
we do not use JNI to implement our native methods.
Changing this would be painful for us, and, I think, not worthwhile.
If we really need a copying collector, we'll just do it in the
Jon> I'm just considering the fact that it doesn't have enormous
Jon> impact on native methods and would allow the use of copying
Jon> collectors to eliminate memory fragmentation and provide more
Jon> precise and determinstic GC.
Whether the impact is enormous depends on whether you're going through
the existing code and making the changes :-).
But seriously, how bad a problem is fragmentation in practice? And
aren't there other ways to combat it? For instance, you could have a
collector that is tunable in some way (useful if you know the
application's behavior in advance). Or you could do mostly-copying
collection without using indirection; this would shift the performance
impact from field references into the GC. This might even be a win; I
More information about the Java