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 number of
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
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
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
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 do
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 are
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 completely
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
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(Level
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
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
context.
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()' just look at the
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 to
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()' and
[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
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
Hi,
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
assignable to the class in
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
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
19 matches
Mail list logo
