David I don't think there is an easy solution to this as it is unlikely
David that a single VMInterface will fit the needs of all VMs perfectly.
David In some cases (java.lang.ref.* for example), I don't think that it
David is reasonable for classpath to try to provide an implementation
David that
To:
Andrew Haley [EMAIL PROTECTED]
cc:
David P Grove/Watson/[EMAIL PROTECTED], GNU
Classpath [EMAIL PROTECTED]
Subject:
Re: VMInterface addition: Make native
library namespart
ofVMInterface
David I don't think there is an easy solution
to this as it is unlikely
David that a single
- Original Message -
Tom Tromey writes:
David I don't think there is an easy solution to this as it is unlikely
David that a single VMInterface will fit the needs of all VMs perfectly.
David In some cases (java.lang.ref.* for example), I don't think that it
David is reasonable for
Hi,
On Wed, 2003-11-05 at 21:31, Bryce McKinlay wrote:
On Nov 5, 2003, at 5:56 AM, Jeroen Frijters wrote:
I think that is in fact what Mark was suggesting and I think this is
definitely a good idea. There are a lot of VMs that don't (want to) use
JNI for their native methods. Having all
Mark Wielaard writes:
Hopefully we won't do it at the expense of elegance 'and' efficiency,
but I agree that sometimes it won't be possible to achieve both. As our
Hacker Guide puts it (even though it leaves out elegance):
When you write code for Classpath, write with three
On Thursday 06 November 2003 12:04, Sascha Brawer wrote:
Andrew Haley [EMAIL PROTECTED] wrote on Thu, 6 Nov 2003 10:28:24 +:
[having the VMInterfaces classes clearly marked as 'special'
would make it easy for VMs and compilers to just inline all calls
to them]
It's not particularly
Sascha Brawer writes:
Andrew Haley [EMAIL PROTECTED] wrote on Thu, 6 Nov 2003 10:28:24 +:
[having the VMInterfaces classes clearly marked as 'special'
would make it easy for VMs and compilers to just inline all calls
to them]
It's not particularly difficult to do, but at the
Jikes RVM uses a mostly unmodifed classpath.
We don't require users to patch any classpath sources, but there
are currently 12 non-VM classes for which we provide our own implementation.
java.lang.ref:
PhantomReference, Reference, SoftReference, WeakReference
java.lang:
Class, Object,
Mark Wielaard wrote:
I think that is in fact what Mark was suggesting and I think this is
definitely a good idea. There are a lot of VMs that don't (want to) use
JNI for their native methods. Having all native methods in the VM*
classes makes this much easier.
I was suggesting that. Sorry for
I am also strongly in favor of putting all VM-specific
native methods in
VM* classes, and all library-specific native methods outside of VM*
classes.
I suspect the notion of a VM-specific native method
vs. a library-specific native method is pretty fuzzy. One example
is VMFloat, most VM's
David P Grove writes:
I don't think there is an easy solution to this as it is unlikely
that a single VMInterface will fit the needs of all VMs perfectly.
In some cases (java.lang.ref.* for example), I don't think that it
is reasonable for classpath to try to provide an implementation
Patrik Reali writes:
Jeroen wrote:
Bryce McKinlay wrote:
Sorry, I think I misunderstood your message. I thought you were
suggesting moving all the native methods (eg for IO classes) to
separate VM* classes.
I think that is in fact what Mark was suggesting and I think this
On Nov 5, 2003, at 5:56 AM, Jeroen Frijters wrote:
Bryce McKinlay wrote:
Sorry, I think I misunderstood your message. I thought you were
suggesting moving all the native methods (eg for IO classes) to
separate VM* classes.
I think that is in fact what Mark was suggesting and I think this is
Bryce McKinlay wrote:
Sorry, I think I misunderstood your message. I thought you were
suggesting moving all the native methods (eg for IO classes) to
separate VM* classes.
I think that is in fact what Mark was suggesting and I think this is
definitely a good idea. There are a lot of VMs that
Jeroen wrote:
Bryce McKinlay wrote:
Sorry, I think I misunderstood your message. I thought you were
suggesting moving all the native methods (eg for IO classes) to
separate VM* classes.
I think that is in fact what Mark was suggesting and I think this is
definitely a good idea. There are
15 matches
Mail list logo
