Etienne Gagnon wrote:
I am starting to have difficulty understanding Classpath's goals and
motivations.
When I proposed to add to Classpath some mechanism to allow it to be
customized to each VM, I was told that it would be a heresy to encode
any VM-specific thing into Classpath, as the vision
Steven Augart wrote:
> If the RawData type were to be used, would you be able to share a
> Classpath installation with other Classpath-based virtual machines?
For some purposes yes. For performance (and some bootstrapping) reasons
I compile Classpath code ahead of time to a CLI assembly, so at ru
If the RawData type were to be used, would you be able to share a
Classpath installation with other Classpath-based virtual machines?
--Steve Augart
Jeroen Frijters wrote:
Steven Augart wrote:
If we were to do this in the GNU Classpath Java code, then the only
solution I see is to use a prepro
Stuart Ballard wrote:
> 2) "Unusual" VMs: Things where JNI-centric assumptions don't
> hold true.
> For example, IKVM and Jaos(?) don't use JNI at all within
> Classpath, and their natural "pointer" type is just a normal
> object reference. gcj with CNI also falls into this category.
I'd like t
Archie Cobbs wrote:
> Note: by this logic byte[] is the most portable/generic way to hold
> VM private data. It places no portability restrictions, only
> (possibly) performance ones. However, I have yet to hear a
> convincing argument that proves byte[] is slower than RawData
> (or whatever) on A
Steven Augart wrote:
> If we were to do this in the GNU Classpath Java code, then the only
> solution I see is to use a preprocessor, and expand gpointer
> to an int or long as appropriate, based upon the standard pointer
> representation in that platform's usual ABI.
That wouldn't work for me
Etienne Gagnon wrote:
> Jeroen Frijters wrote:
> >>>Indeed. The goal is to find the optimal solution that would be spec
> >>>compliant, portable and efficient.
>
> and later:
> > I'm not the one nitpicking about pure ISO C portability (I don't use
> > JNI, so I couldn't care less), ...
>
> and la
Andrew Haley wrote:
> > Finally, "RawData as opaque
> > pointer" doesn't require any unwraping but does hit GC cycle time
> > severely as every object has to be check for being in this special
> > RawData class. So for JC byte[] is best.
>
> We get away with this in GCJ because a pointer outsi
Archie Cobbs wrote:
Okay, perhaps we need to agree what platforms we care about.
Here are my votes...
- We don't care about platforms that don't have 8 bit bytes or where
typeof(jchar) != signed char.
- We don't care about platforms where 'jlong' is insufficient to hold
VM private data. E.g.,
Archie Cobbs writes:
>
> Note: by this logic byte[] is the most portable/generic way to hold
> VM private data. It places no portability restrictions, only
> (possibly) performance ones. However, I have yet to hear a
> convincing argument that proves byte[] is slower than RawData (or
> whate
Andrew Haley wrote:
Strong typing for legibility and reliability is IMO for more
important.
I strongly agree with this, on software engineering grounds.
> And here it is with named opaque types:
>
> public static final synchronized native int
> g_signal_handlers_unblock_matched(gpointer instance,
Andrew Haley wrote:
> Perhaps we need to define what we're really aiming at.
>
> I would have thought:
>
> 1. Correctness (well-defined on the platforms we care about.)
> 2. Portability (to the platforms we care about.)
> 3. Maintainability/Readability of code.
> 4. Efficiency.
>
> Does anyo
Etienne Gagnon wrote:
the main motivation is for Classpath to use less portable
approaches when
they make CNI faster, as the performance of CNI and the other non-spec
compliant
interfaces is the main objective.
Jikes RVM uses JNI and is unlikely to ever implement CNI. There are
other classpath-
Etienne Gagnon writes:
> Jeroen Frijters wrote:
> >>>Indeed. The goal is to find the optimal solution that would be spec
> >>>compliant, portable and efficient.
>
> and later:
> > I'm not the one nitpicking about pure ISO C portability (I don't use
> > JNI, so I couldn't care less), ...
>
Jeroen Frijters wrote:
Indeed. The goal is to find the optimal solution that would be spec
compliant, portable and efficient.
and later:
I'm not the one nitpicking about pure ISO C portability (I don't use
JNI, so I couldn't care less), ...
and later:
and is of thus ranks lower than my proposal on
Etienne Gagnon writes:
>
> Now that my proposal has been criticised to death on the smallest
> nitpicks of pure ISO C portability, let me comment on the portability
> ]of your code.
>
>
> The ISO C standard says:
>
> [#6] Any pointer type may be converted to an integer type;
Jeroen Frijters writes:
>
> > > return env->NewObject(pclass, mid, p);
> >
> > ** Bzzzt *** Please try again...
> >
> > Now that my proposal has been criticised to death on the smallest
> > nitpicks of pure ISO C portability, let me comment on the portability
> > of your code.
That wa
Jeroen Frijters wrote:
Indeed. The goal is to find the optimal solution that would be spec
compliant, portable and efficient. Since I obviously believe that my
proposal is better than the byte[] proposal, I would like to convice
Etienne (and you) of this. I fail to see how you can take issue with
t
Etienne Gagnon wrote:
> Jeroen Frijters wrote:
> > Indeed. The goal is to find the optimal solution that would be spec
> > compliant, portable and efficient. Since I obviously believe that my
> > proposal is better than the byte[] proposal, I would like to convice
> > Etienne (and you) of this. I f
Etienne Gagnon wrote:
Andrew Haley wrote:
Okay, but ANS specifically does not allow you to do this subtraction.
Also, there is no guarantee that every pointer is representable as a
ptrdiff_t. (6.5.6 Para 9, if you're interested)
The point is: if your platform is one that does *not* have 8-bit c
Grzegorz B. Prokopski wrote:
> On (07/04/04 13:47), Jeroen Frijters wrote:
> > Andrew Haley wrote:
> > > This seems to be identical to my proposal.
> > >
> > > I no longer understand what we're arguing about...
> >
> > I know. I thought we were still trying to convince Etienne :-)
>
> I thought
Hi Etienne,
while I think that your proposal would work with our VM it would also be quite
ineficient.
Our arrays can be fragemented so we nee to do some magic when accessing them in native
code.
Do you have any system that requires a pointer size larger than 64bits ?
My feeling is that once we
Andrew Haley wrote:
Okay, but ANS specifically does not allow you to do this subtraction.
Also, there is no guarantee that every pointer is representable as a
ptrdiff_t. (6.5.6 Para 9, if you're interested)
The point is: if your platform is one that does *not* have 8-bit chars (!!!),
then you can
Per Bothner wrote:
> I can see on a few JVMs it may cause problems,
> but they can easily sed the source to convert RawData to long.
> Just think of RawData has a macro.
I am starting to have difficulty understanding Classpath's goals and
motivations.
When I proposed to add to Classpath som
Per Bothner writes:
> Jeroen Frijters wrote:
>
> > That's why I'm very much in favor of using RawData. ...
> >
> > public abstract class RawData {}
> >
> > public final class RawData32 extends RawData
> > {
> > private int pointer;
> > }
> >
> > public final class RawData64 exten
Etienne Gagnon writes:
> On Wed, Apr 07, 2004 at 11:42:08AM +0100, Andrew Haley wrote:
> > > Platform = Machine + OS. I don't have any reference, but I believe that
> > > Etienne is right in saying that the same library should be usuable with
> > > all JVMs on a specific platform.
> >
> >
Per Bothner wrote:
> Jeroen Frijters wrote:
>
> > That's why I'm very much in favor of using RawData. ...
> >
> > public abstract class RawData {}
> >
> > public final class RawData32 extends RawData
> > {
> > private int pointer;
> > }
> >
> > public final class RawData64 extends RawData
>
On Wed, Apr 07, 2004 at 11:42:08AM +0100, Andrew Haley wrote:
> > Platform = Machine + OS. I don't have any reference, but I believe that
> > Etienne is right in saying that the same library should be usuable with
> > all JVMs on a specific platform.
>
> But it's not necessarily possible. Clea
Jeroen Frijters wrote:
That's why I'm very much in favor of using RawData. ...
public abstract class RawData {}
public final class RawData32 extends RawData
{
private int pointer;
}
public final class RawData64 extends RawData
{
private long pointer;
}
All the Java code would ever see are R
Etienne Gagnon writes:
> On Wed, Apr 07, 2004 at 11:19:47AM +0100, Andrew Haley wrote:
> > > "jbyte" must have a single platform-specific definition, as all
> > > JVMs on that platform should be able to execute the same JNI
> > > library code (no recompilation required).
> >
> > I didn't
On Wed, Apr 07, 2004 at 11:19:47AM +0100, Andrew Haley wrote:
> > "jbyte" must have a single platform-specific definition, as all
> > JVMs on that platform should be able to execute the same JNI
> > library code (no recompilation required).
>
> I didn't know that. Is that requirement documente
So,
I
have to admit that I haven't been following this thread in all of its glory
:-), but the JNI spec is quite clear on the sizes of the various primitives.
See the table in section 12.1.1 of the spec. A jbyte is signed
8 bit quantity. A jchar is an unsigned 16 bit quantity, etc. Th
Andrew Haley wrote:
> This seems to be identical to my proposal.
>
> I no longer understand what we're arguing about...
I know. I thought we were still trying to convince Etienne :-)
Regards,
Jeroen
___
Classpath mailing list
[EMAIL PROTECTED]
http:/
Etienne Gagnon writes:
> Andrew Haley wrote:
> > Maybe, but that's not the only thing. It's possible to define jbyte
> > so that it is an 8 bit signed value but not a character type, and JNI
> > does not forbid this. I suspect that all the platforms we use define
> > jbyte to be a character
Jeroen Frijters writes:
> Andrew Haley wrote:
> > > "jbyte" must have a single platform-specific definition, as all
> > > JVMs on that platform should be able to execute the same JNI
> > > library code (no recompilation required).
> >
> > I didn't know that. Is that requirement documente
Andrew Haley wrote:
> > "jbyte" must have a single platform-specific definition, as all
> > JVMs on that platform should be able to execute the same JNI
> > library code (no recompilation required).
>
> I didn't know that. Is that requirement documented anywhere? I can't
> see how you'd do it
Etienne Gagnon writes:
> Andrew Haley wrote:
> > Yes, but it's not a question of whether the type jbyte is the same
> > size as a character type, but whether it is treated in the same way as
> > a character by the compiler.
>
> Hi Andrew. Please look carefully at my proposal (sent minutes a
Etienne Gagnon wrote:
> Can JNI actually be implemented on a 16-bit per byte system?
> Anybody has a reasonable answer?
Such a system, to implement JNI, will have to have a compiler-defined
extension for a signed 8-bit byte type, a bit like the GNU "long long"
extension. ANSI C allows a compiler
Quoting Etienne Gagnon ([EMAIL PROTECTED]):
> I would really like to see the native counterpart of your opaque types and
> compare the "theoretical" performance of it relative to the byte array
> proposal.
Sorry if I lost track of the discussion, but when the proposal of an
abstract class for virt
Andrew Haley wrote:
Yes, but it's not a question of whether the type jbyte is the same
size as a character type, but whether it is treated in the same way as
a character by the compiler.
Hi Andrew. Please look carefully at my proposal (sent minutes ago),
and tell me if it still contains non-portab
Andrew Haley wrote:
Maybe, but that's not the only thing. It's possible to define jbyte
so that it is an 8 bit signed value but not a character type, and JNI
does not forbid this. I suspect that all the platforms we use define
jbyte to be a character type, but I can see no overpowering reason to
Etienne Gagnon writes:
>
> Do we actually have to deal with platforms that have non 8-bit chars?
> I guess quite a few other things/algorithms in the class library would
> break if it is so...
>
> It's fine to be pedantic, but up to a point...
>
> FYI: The JNI specification guarantees th
David Holmes writes:
> Well if we're being pedantic and imprecise to boot ...
>
> > >> malloc() returns a char*, not a jbyte*.
>
> malloc() returns void* not char*. It hasn't returned char* since pre ANSI C.
True, yes.
> Hence the pointer returned by malloc can be legally converted to any
Etienne Gagnon writes:
> Etienne Gagnon wrote:
> > FYI: The JNI specification guarantees that jbyte is an 8-bit signed value.
>
> Hmmm... Thinking about all this mess of "non-specified" C byte length...
>
> Can JNI actually be implemented on a 16-bit per byte system?
> Anybody has a reaso
Etienne Gagnon writes:
> I should have compiled with -pedantic, of course... I've included a few fixes
> in the attachment.
>
> >> malloc() returns a char*, not a jbyte*.
>
> [#1] byte
> addressable unit of data storage large enough to hold any
> member of th
Etienne Gagnon writes:
> Andrew Haley wrote:
> > malloc() returns a char*, not a jbyte*.
>
> So, can you tell me the difference between a jbyte and a "signed char"?
>
> > Sigh. No it isn't, and this code will break with gcc.
>
> OK, maybe I am tired and I don't see it. GCC -Wall does n
Etienne Gagnon wrote:
> There is a single JNI source code source base, used by everyone.
Please don't say that. Not everyone uses the C part of Classpath.
Besides, if you want NIO (we are still talking about NIO, right?) to
perform well, you're going to need some VM magic.
Regards,
Jeroen
_
Etienne Gagnon wrote:
FYI: The JNI specification guarantees that jbyte is an 8-bit signed value.
Hmmm... Thinking about all this mess of "non-specified" C byte length...
Can JNI actually be implemented on a 16-bit per byte system?
Anybody has a reasonable answer?
To consider:
5.2.4.2.1 Siz
Well if we're being pedantic and imprecise to boot ...
> >> malloc() returns a char*, not a jbyte*.
malloc() returns void* not char*. It hasn't returned char* since pre ANSI C.
Hence the pointer returned by malloc can be legally converted to any real
pointer type with clearly defined semantics.
I should have compiled with -pedantic, of course... I've included a few fixes
in the attachment.
malloc() returns a char*, not a jbyte*.
[#1] byte
addressable unit of data storage large enough to hold any
member of the basic character set of the execution
e
Andrew Haley wrote:
malloc() returns a char*, not a jbyte*.
So, can you tell me the difference between a jbyte and a "signed char"?
Sigh. No it isn't, and this code will break with gcc.
OK, maybe I am tired and I don't see it. GCC -Wall does not complain
about the attached example.
... Also, "w
Archie Cobbs writes:
> Andrew Haley wrote:
> > > Prove me wrong with a specific ISO C specification clause, if you
> > > claim otherwise.
> >
> > I spent a long time working on and supporting gcc, and this is the
> > rule I've had to refer people to more times than any other. It's
> > am
Andrew Haley wrote:
> > Prove me wrong with a specific ISO C specification clause, if you
> > claim otherwise.
>
> I spent a long time working on and supporting gcc, and this is the
> rule I've had to refer people to more times than any other. It's
> amazing how many programmers don't know the
Etienne Gagnon writes:
> For one thing, you have not shown me *your* native part.
>
> Second, see below.
>
> Andrew Haley wrote:
> > > JNIEXPORT void JNICALL
> > > Java_somepackage_someNativeMethod
> > >(JNIEnv *env, jobject this, jbyteArray nativePointer, ...)
> > >
> > > {
For one thing, you have not shown me *your* native part.
Second, see below.
Andrew Haley wrote:
> JNIEXPORT void JNICALL
> Java_somepackage_someNativeMethod
>(JNIEnv *env, jobject this, jbyteArray nativePointer, ...)
>
> {
>void *ptr;
>(*env)->GetByteArrayRegion(env, nativePoi
Etienne Gagnon writes:
> Andrew Haley wrote:
> > Sure. Instead of putting a native pointer in a long or in a byte[],
> > you just declare a class with a single field that contains the
> > pointer. Everyone who needs a pointer makes a suitably named
> > subclass, so they'll know what they're
Michael Koch writes:
> Am Montag, 5. April 2004 19:30 schrieb Andrew Haley:
> > Michael Koch writes:
> > > I think Andrew's solution might be viable. His solution is
> > > already used in SWT. SWT runs with SUN JRE so it seems to be
> > > portable enough for us.
> >
> > Well, not exactly
Michael Koch writes:
> Am Montag, 5. April 2004 20:06 schrieb Andrew Haley:
> > Etienne Gagnon writes:
> > > Andrew Haley wrote:
> > > > Well, not exactly: I'm suggesting that we wrap all those longs
> > > > in an opaque type. But otherwise, yes.
> > >
> > > So, how do you do opaque ty
Andrew Haley wrote:
Sure. Instead of putting a native pointer in a long or in a byte[],
you just declare a class with a single field that contains the
pointer. Everyone who needs a pointer makes a suitably named
subclass, so they'll know what they're pointing to.
How is that more efficient than a
Am Montag, 5. April 2004 20:06 schrieb Andrew Haley:
> Etienne Gagnon writes:
> > Andrew Haley wrote:
> > > Well, not exactly: I'm suggesting that we wrap all those longs
> > > in an opaque type. But otherwise, yes.
> >
> > So, how do you do opaque types, in Java?
>
> You write the code using
Etienne Gagnon writes:
> Andrew Haley wrote:
> > Well, not exactly: I'm suggesting that we wrap all those longs in an
> > opaque type. But otherwise, yes.
>
> So, how do you do opaque types, in Java?
You write the code using a class that wraps your native pointer: a
class with a single me
Etienne Gagnon writes:
> Andrew,
>
> Andrew Haley wrote:
> > - Everyone who can use a long as a pointer (and, in practice, this is
> > everyone) will do so.
>
> It's *NOT* the VM interface! There is a single JNI source code
> source base, used by everyone.
It's easy to parameterize.
Andrew Haley wrote:
Well, not exactly: I'm suggesting that we wrap all those longs in an
opaque type. But otherwise, yes.
So, how do you do opaque types, in Java? And how do you guarantee portability
to 128bit systems?
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egag
Am Montag, 5. April 2004 18:50 schrieb Etienne Gagnon:
> Andrew,
>
> Andrew Haley wrote:
> > - Everyone who can use a long as a pointer (and, in practice, this
> > is everyone) will do so.
>
> It's *NOT* the VM interface! There is a single JNI source code
> source base, used by everyone.
>
> So, t
Am Montag, 5. April 2004 19:30 schrieb Andrew Haley:
> Michael Koch writes:
> > I think Andrew's solution might be viable. His solution is
> > already used in SWT. SWT runs with SUN JRE so it seems to be
> > portable enough for us.
>
> Well, not exactly: I'm suggesting that we wrap all those lo
Michael Koch writes:
> I think Andrew's solution might be viable. His solution is already
> used in SWT. SWT runs with SUN JRE so it seems to be portable
> enough for us.
Well, not exactly: I'm suggesting that we wrap all those longs in an
opaque type. But otherwise, yes.
Andrew.
Andrew,
Andrew Haley wrote:
- Everyone who can use a long as a pointer (and, in practice, this is
everyone) will do so.
It's *NOT* the VM interface! There is a single JNI source code source base,
used by everyone.
So, there is no "SableVM" does it this way, gcj that way, and Kaffe the other.
It
Am Montag, 5. April 2004 18:07 schrieb Andrew Haley:
> Jeroen Frijters writes:
> > Andrew Haley wrote:
> > > Michael Koch writes:
> > > > > To be honest I think we should not have RawData in
> > > > > Classpath.
> > >
> > > The trouble with RawData (as it is used in gcj) is that it
> > > b
Jeroen Frijters writes:
> Andrew Haley wrote:
> > Michael Koch writes:
> > > > To be honest I think we should not have RawData in Classpath.
> >
> > The trouble with RawData (as it is used in gcj) is that it breaks the
> > Java type system. Its bizarre semantics mean that you have somethin
Jeroen,
Jeroen Frijters wrote:
>>IMO, the cleanest approach is really the use of a byte array.
>
> But it is inefficient and hard to optimize. I don't see why RawData
> doesn't give you the same capabilities as a byte array (as an extreme
> example, you can replace Classpath's RawData with your ow
Etienne Gagnon writes:
>
> IMO, the cleanest approach is really the use of a byte array.
Well, I tell you what: we could wrap the {byte[],long} in an opaque
type, call it a "native pointer", and be done with it.
- Everyone who can use a long as a pointer (and, in practice, this is
everyone)
I Agree with Andrew, regarding the reference JNI library code; this code is
*NOT* the VM*.java interface, so it should be written to be compatible
with any JNI compliant JVM. As far as I know, disguising a native
pointer into a Java reference is not portable across JVMs.
IMO, the cleanest approac
Andrew Haley wrote:
> Michael Koch writes:
> > > To be honest I think we should not have RawData in Classpath.
>
> The trouble with RawData (as it is used in gcj) is that it breaks the
> Java type system. Its bizarre semantics mean that you have something
> that looks like an object reference bu
Am Montag, 5. April 2004 16:16 schrieb Andrew Haley:
> Michael Koch writes:
> > > Uh, I don't understand what you mean, sorry. Why is a Java
> > > reference the same size as a native pointer? Perhaps I
> > > misunderstood you.
> >
> > AFAIK a java refernce is a pointer and this pointer can p
Andrew Haley writes:
> Michael Koch writes:
> > >
> > > Uh, I don't understand what you mean, sorry. Why is a Java reference
> > > the same size as a native pointer? Perhaps I misunderstood you.
> >
> > AFAIK a java refernce is a pointer and this pointer can point
> > everywhere. R
Michael Koch writes:
> >
> > To be honest I think we should not have RawData in Classpath.
The trouble with RawData (as it is used in gcj) is that it breaks the
Java type system. Its bizarre semantics mean that you have something
that looks like an object reference but you can't use it as one.
Michael Koch writes:
> >
> > Uh, I don't understand what you mean, sorry. Why is a Java reference
> > the same size as a native pointer? Perhaps I misunderstood you.
>
> AFAIK a java refernce is a pointer and this pointer can point
> everywhere. Right ?
No, not at all. A java reference
Am Montag, 5. April 2004 15:10 schrieb Andrew Haley:
> Michael Koch writes:
> > > To be honest I think we should not have RawData in Classpath.
>
> The trouble with RawData (as it is used in gcj) is that it breaks the
> Java type system. Its bizarre semantics mean that you have something
> that l
Michael Koch wrote:
> The RawData pointer will get the real address to a native
> memory region.
> It can be directly used and has always the pointer size of the
> platform. There will never be problems on platforms with more then 64
> bit. Its really simply. Its just not done in classpath yet
Am Sonntag, 4. April 2004 16:15 schrieb Mark Wielaard:
> Hi,
>
> On Mon, 2004-03-29 at 16:47, Michael Koch wrote:
> > Am Montag, 29. März 2004 17:12 schrieb Andrew Haley:
> > > Archie Cobbs writes:
> >
> > [...]
> >
> > > > Object is good because it is automatically the size of a
> > > > pointer
Mark Wielaard writes:
>
> As Andrew says we could maybe just use long if we want to store an
> address. Andrew also worked hard on getting SWT (Eclipse) 64 bit clean.
> What I have seen from the (huge) patch this was mainly done by turning
> addresses as stored by JNI from int to long. BTW, w
Hi,
On Mon, 2004-03-29 at 18:42, Etienne Gagnon wrote:
> Etienne Gagnon wrote:
> > vmData = new byte[PTR_SIZE];
> > or
> > vmData = new RawData();
> > or whatever.
> > So what's the problem, with this?
>
> And for those who want to do:
>
>vmData = [internalVMpointer]
>
> They can deal w
Hi,
On Mon, 2004-03-29 at 16:47, Michael Koch wrote:
> Am Montag, 29. März 2004 17:12 schrieb Andrew Haley:
> > Archie Cobbs writes:
> [...]
> > > Object is good because it is automatically the size of a pointer
> > > on any platform. However, it has one significant disadvantage,
> > > which is
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
Mark> I admit not to have looked into or thought about java.lang.ref support
Mark> yet. How many VMs based on GNU Classpath properly implement those?
libgcj claims to :-). We had to hack Reference.java a little.
http://gcc.gnu.org/jav
Hi!
We have our own version of the classes in java.lang.* so this dicussion is not vital for us.
For us it is important that after the initial memory allocation there is no further memory
allocation. So if we need to store native information we need to put it into the Java heap. To do
this we a
Andrew Haley wrote:
[] I suppose it's possible that on some weird
platform a pointer mat not fit in long. In gcj was have a class
RawData, which we know points to something that isn't an Object and
isn't gcable.
Jikes RVM abstracts this away with a similar class, VM_Address. And,
as you said
Etienne Gagnon wrote:
vmData = new byte[PTR_SIZE];
or
vmData = new RawData();
or whatever.
So what's the problem, with this?
And for those who want to do:
vmData = [internalVMpointer]
They can deal with it in many ways, such as:
1- make sure [internalVMpointer] points to
a non-GC'ed mem
Archie Cobbs wrote:
Eeeh. I can't imagine that either. If there's a strong argument for
holding native pointer in a byte[] ?
Object is good because it is automatically the size of a pointer
on any platform. However, it has one significant disadvantage, which
is that you must special case all such
Andrew Haley wrote:
> > > I would like the vmdata field type then to be VMClass not Object.
> >
> > I disagree, as it imposes a restriction on what vmData actually
> > is. The most obvious implementation of vmData is to be a byte[]
> > instance holding the byte of a native pointer to an inte
Robert Lougher wrote:
- My Thread class uses private objects to implement sleep() and join()
in terms of Object.wait(). The VM notify()'s this object when the
thread exits. This means all the complexity of sleeping (and handling
Thread.interrupt()) can be put in Object.wait() and not dup
Am Montag, 29. März 2004 17:12 schrieb Andrew Haley:
> Archie Cobbs writes:
> > Andrew Haley wrote:
> > > > > > I would like the vmdata field type then to be VMClass not
> > > > > > Object.
> > > > >
> > > > > I disagree, as it imposes a restriction on what vmData
> > > > > actually is.
Mark Wielaard wrote:
environment. By marking the VMWhatever classes as package local, final
and naming them specially I had kind of hoped that Compilers/VMs would
easily inline/optimize away extra calls and/or inline VM-specific fields
in the non-VM specific instance. Maybe something for the future
> I would be interested in a quick poll of VM implementors
using Classpath:
> do you care more about having fewer diffs with "stock" Classpath
or
> modifying & optimizing your VM's core classes to eke out optimal
> performance?
Both of course ;-)
More seriously, I'm a little cautious when thinki
Archie Cobbs writes:
> Andrew Haley wrote:
> > > > > I would like the vmdata field type then to be VMClass not Object.
> > > >
> > > > I disagree, as it imposes a restriction on what vmData actually
> > > > is. The most obvious implementation of vmData is to be a byte[]
> > > > instanc
Answering Mark's question: Why does
Jikes RVM override 11 non-VMFoo classes?
(1) Native methods: For us, native
methods are (1) lower performance and (2) can't be used early in the VM
booting process. This is the primary reason for java.lang.Object,
java.lang.reflect.Field, java.lang.reflect.Me
Could you post your versions? It might be interesting to see whether we
can adopt this approach as default in the vm/reference implementation.
VMThread now does have a lot of native methods. But I believe I
discussed some of these issues with Jeroen and if I remember correctly
there were some subtl
On Sun, 2004-03-28 at 23:53, Archie Cobbs wrote:
> Mark Wielaard wrote:
> > I had hoped that the VM interface for Class, Object, Thread and
> > Throwable was usable for most VMs. What isn't in your case?
>
JamVM 1.1.1 uses no special versions of these classes (i.e. it uses the
VMClass, VMObject an
Jeroen Frijters writes:
> Etienne Gagnon wrote:
> > Mark Wielaard wrote:
> > > I would like the vmdata field type then to be VMClass not Object.
> >
> > I disagree, as it imposes a restriction on what vmData actually
> > is. The most obvious implementation of vmData is to be a byte[]
> > i
Hi,
On Sun, 2004-03-28 at 23:53, Archie Cobbs wrote:
> Mark Wielaard wrote:
> > I had hoped that the VM interface for Class, Object, Thread and
> > Throwable was usable for most VMs. What isn't in your case?
>
> Although this question wasn't asked at me I'll answer on behalf of
> the JC implement
David Holmes wrote:
- I avoid VMFoo instances (i.e, shadow objects). It seems to me that
storing VM specific info in a shadow object serves no (runtime) purpose:
if it can be represented in Java, store it in the original object,
if it can't store it in a native C structure or whatever.
But ju
1 - 100 of 130 matches
Mail list logo
