> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
Andrew> IMO trying to unify low-level stack walker code is unnecessary and
Andrew> leads to too many compromises; it's a merge too far.
It would be preferable from a maintenance point of view if we could
find a way to merge this. A fair
Am Montag, den 25.07.2005, 10:16 +0200 schrieb Jeroen Frijters:
> Ingo Prötel wrote:
> > I just implemented VMStackWalker for our VM and have some questions.
> >
> > The reference implementation of 'getCallingClass()' and
> > 'getCallingClassLoader()' just look at the third entry in the class
> >
Andrew Haley wrote:
> Of course, yes. But it's security issues that I'm concerned about
> here: what we want to know is the first caller of Foo.method() that is
> not Foo.
Not necessarily. Typically what's important is the supplier of the arguments to
the method. In the subclassing scenario, the
Ingo Prötel wrote:
> I really like the idea of having a stack walker so I would like to use
> it wherever possible. For example in java.util.logging.Logger. If a
> class calls 'logger.warning("some warning")' this call will
> be forwarded through a couple of calls until it will call
> 'Logger.log(
Andrew Haley wrote:
> Which is the Right Answer: the caller of baz *is* Frob.
It *may* be the right answer, but how can you be certain that the coder of
class Foo intended this? IMNSHO, code like this is completely unauditable
(remember, this isn't just a correctness issue, access to class loade
Jeroen Frijters writes:
> Andrew Haley wrote:
> > Which is the Right Answer: the caller of baz *is* Frob.
>
> It *may* be the right answer, but how can you be certain that the
> coder of class Foo intended this?
Ah, well that is a totally different matter.
> IMNSHO, code like this is compl
Jeroen Frijters writes:
> Andrew Haley wrote:
> > However, as for overhead -- I don't believe it. I doubt that not
> > having this parameter saves anything much on any VM.
>
> That's just your lack of imagination ;-) I was concerned with two
> aspects wrt performance:
> 1) Class literals a
Jeroen Frijters writes:
> Andrew Haley wrote:
> > In gcj, we have a method called GetCallingClass(Class c). It searches
> > firstly for a method declared in class c, then for a method not
> > declared in c. We have found, after a certain amount of trouble, that
> > this is the right way to d
Andrew Haley wrote:
> However, as for overhead -- I don't believe it. I doubt that not
> having this parameter saves anything much on any VM.
That's just your lack of imagination ;-) I was concerned with two
aspects wrt performance:
1) Class literals are inefficient -- this is no longer an issue
Andrew Haley wrote:
> In gcj, we have a method called GetCallingClass(Class c). It searches
> firstly for a method declared in class c, then for a method not
> declared in c. We have found, after a certain amount of trouble, that
> this is the right way to do things; it means that an arbitrary nu
Ingo Prötel wrote:
> I just implemented VMStackWalker for our VM and have some questions.
>
> The reference implementation of 'getCallingClass()' and
> 'getCallingClassLoader()' just look at the third entry in the class
> context. Would it not be better to return the first class that is not
> assi
Mark Wielaard writes:
>
> On Fri, 2005-07-22 at 18:01 +0100, Andrew Haley wrote:
> > Ingo Prötel writes:
> >
> > > I just implemented VMStackWalker for our VM and have some questions.
> > >
> > > The reference implementation of 'getCallingClass()' and
> > > 'getCallingClassLoader()'
Ingo Prötel wrote:
I would like to get the common case where private or protected methods
are called before the actual stack check happens. This changes the
current semantic but I feel that it would be more useful and less
fragile to changes of classes that want to use VMStackWalker. If there
is
[EMAIL PROTECTED] wrote:
The next thing I would like to have is a method to get the calling
method name. This would be good for logging.
You could create a Throwable() object and then get the StackFrame[].
That is what the logging API currently does. But that's terrribly
inefficient. We could
Am Freitag, den 22.07.2005, 23:59 +0200 schrieb Mark Wielaard:
> Hi,
>
> On Fri, 2005-07-22 at 18:01 +0100, Andrew Haley wrote:
> > Ingo Prötel writes:
> >
> > > I just implemented VMStackWalker for our VM and have some questions.
> > >
> > > The reference implementation of 'getCallingClass()
>> The next thing I would like to have is a method to get the calling
>> method name. This would be good for logging.
>
> You could create a Throwable() object and then get the StackFrame[].
>
That is what the logging API currently does. But that's terrribly
inefficient. We could add a new method
Hi,
On Fri, 2005-07-22 at 18:01 +0100, Andrew Haley wrote:
> Ingo Prötel writes:
>
> > I just implemented VMStackWalker for our VM and have some questions.
> >
> > The reference implementation of 'getCallingClass()' and
> > 'getCallingClassLoader()' just look at the third entry in the class
Ingo Prötel writes:
> I just implemented VMStackWalker for our VM and have some questions.
>
> The reference implementation of 'getCallingClass()' and
> 'getCallingClassLoader()' just look at the third entry in the class
> context. Would it not be better to return the first class that is not
18 matches
Mail list logo
