This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: [freenet-tech] Technology / Features
- From: Tom Tromey <tromey at redhat dot com>
- To: davidm at hpl dot hp dot com
- Cc: "Boehm, Hans" <hans_boehm at hp dot com>, Jeff Sturm <jsturm at one-point dot com>, Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>, java at gcc dot gnu dot org
- Date: 02 Apr 2002 15:33:17 -0700
- Subject: Re: [freenet-tech] Technology / Features
- References: <40700B4C02ABD5119F000090278766443BF024@hplex1.hpl.hp.com> <15488.5923.494636.128959@napali.hpl.hp.com> <877kovocny.fsf@creche.redhat.com> <15488.20823.255249.650537@napali.hpl.hp.com>
- Reply-to: tromey at redhat dot com
>>>>> "David" == David Mosberger <davidm@napali.hpl.hp.com> writes:
Tom> Anyway, our interpreter is a pretty standard bytecode
Tom> interpreter. The PC ranges reported on the stack will always
Tom> be in one particular method. We'd need to be able to specify
Tom> the real underlying class/method name on a per-thread basis.
David> Hmmh, the LSDA is associated with a particular code range, so
David> it's not per thread. I'm not sure the LSDA would buy you much
David> more than a way to identify a particular frame as being an
David> interpreter frame. If so, there are probably easier ways to
David> accomplish this.
I guess what we can do is have our interpreter generate more
information. We can stack-allocate a frame descriptor that has
information about a given interpreter frame's class and method. Then
we can link these together and put the information into a per-thread
variable. Our unwinder can then look in this data structure when it
finds an interpreter frame.
Tom