Hi Todd;
Todd L. Miller wrote:
>
> w.r.t. dynamic libraries, no, it's not a priority right now, but a
> little foresight is always worthwhile...
>
> w.r.t. to speeding up native-code access even farther: why don't
> we check if the method is native before handing it off to builtins lookup?
Obviously, this is a much better way to do things. However, I didn't do that
because I thought there were some methods in the JDK we absolutely didn't want
to run (I deduced this, apparently incorrectly, from the way the original code
was written).
> Originally, it was set up this way because Bad Things would happen trying
> to use System.[in|err].print[ln] as a debugging tool... however, decaf has
> gotten much more capabale since I wrote those methods in. It would be
Great, I completely misinterpreted the reasons for this, then. (That's a good
thing, actually.)
> worthwhile to try adding a native check before the builtin lookup, and see
We are already checking (and thus paying a cost for) this... So, I will just
change the code around to only check the built-in table if and only if the
resolved_method* tells me that it's a native method. This should be a
reasonably big performance win.
> if things got far enough along to write in a native-only call. (Likewise,
> make sure that in8(), etc, calls were actually marked as native.)
It is my understanding that this is already the case (except maybe for the
print() and println() methods...). Any idea how that works from your prior
experience with this?
-jm
--
==== John Morrison ==== MaK Technologies, Inc.
==== Chief Technology Officer ==== 185 Alewife Brook Pkwy, Cambridge, MA 02138
==== [EMAIL PROTECTED] ==== http://www.mak.com/welcome.html
==== vox:617-876-8085 x115 ==== fax:617-876-9208
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
