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 later:
and is of
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 ALL
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.
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 to
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
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
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
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 the goal was
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
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 fail to
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
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 wasn't my point in
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 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:
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:
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
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 anyone really
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,
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
whatever)
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.
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 outside the heap
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 ago),
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 on a
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 documented anywhere? I
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 type,
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]
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. There
are
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 documented
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
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. Clearly
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
{
private long
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.
But it's not
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 extends RawData
{
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 some
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
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
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 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 not complain
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 the basic
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 reasonable
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 real
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 that
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
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
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 virtual
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 to
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 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 looks
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 is
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.
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. Right ?
No,
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 point
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 but you
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
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)
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 something
that
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
breaks the Java type
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
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.
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 longs in
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, there is no
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.
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.
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 member.
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 a class that
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
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 types, in Java?
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: I'm
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 pointing
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, nativePointer,
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, ...)
{
void *ptr;
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
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
amazing how many
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
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.
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
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 that you
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 with it in many
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, was
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 on any platform.
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.
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[]
instance
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 and
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
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,
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[]
instance holding the byte of
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 thinking
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
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. The most obvious
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
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 internal VM
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
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
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
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
--On Samstag, 27. März 2004 21:00 -0500 Etienne Gagnon
[EMAIL PROTECTED] wrote:
Note to Patrik: I thought you would have noticed, by now, that I was
only trying to tell about a subset of the VMs that use Classpath without
using 10 words. (See other messages for a better description). I used
Etienne Gagnon wrote:
Hi all,
As most people dislike the m4 approach without even having a look at it
(just remembering m4 as used in auto* stuff...), I will no push for this
further. I have no time for religious wars.
I'd like to say that I wouldn't mind the m4 approach since I'm
interested in
Hi,
On Thu, 2004-03-25 at 21:50, Jeroen Frijters wrote:
David Lichteblau wrote:
BTW, on the topic of VM* classes: Has there been agreement on
java.lang.VMClass? The proposal was to make its methods static (and
possibly add an Object vmdata field to java.lang.Class instead).
I don't
Hi,
On Thu, 2004-03-25 at 22:54, Jeroen Frijters wrote:
No, if you somehow get a Configuration.java (e.g. manually create it),
you can build Classpath by simply running jikes (or another Java
compiler).
BTW. If someone could come up with something better for (most of) the
Hi,
On Sat, 2004-03-27 at 00:56, Steven Augart wrote:
Etienne Gagnon wrote:
[Some VMs, like JikesRVM tend to completely replace some base classes
by their own; SableVM does not].
Jikes RVM's rvmrt.jar overrides exactly eleven non-VM* classes from a
default Classpath installation's
1 - 100 of 125 matches
Mail list logo
