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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: I'm new and wanting to help!


On Thu, 3 Aug 2006, Tom Tromey wrote:

Joel> Would it be possible to use debug information to determine the stack
Joel> layout, similar to how DWARF is used for unwinding?

Yes.  Actually there is a paper from 10 years ago or so where the
authors did just this, in GCC, for Modula-3 as I recall.  As I
remember the paper, it was a lot of work.  And, the patches were never
integrated.

Well, it's nice to know it's possible, anyway. :)


I'm not a GC expert, so I don't know how well this would really
compare to what we've got now.  And, maybe a mostly-copying GC would
serve just as well.

I'm no expert either, but my understanding is that you pick copying GC when you want to maximize cache locality and minimize fragmentation. In order to get an idea of how such a strategy compares with conservative GC, it may be worth benchmarking something like PLT Scheme, which supports either, I believe.


Joel> Also, how might java.util.IdentityHashMap or the hash-synchronization
Joel> option be implemented when using a copying GC, given that object
Joel> addresses may change at any time?

I'm not sure how other VMs do this.  I know earlier ones kept the
"system" hash code in the object header, but I'm not sure whether this
is current practice.

I've just assumed that other VMs don't use copying collectors. One option would be to have support for IdentityHashMaps built in to the GC, so that each instance is rehashed after GC.


- Joel


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