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
> "Steven" == Steven Augart <[EMAIL PROTECTED]> writes:
Thanks, I'm checking this in.
Steven> Author: Steven Augart
Steven> Date: Monday, 29 March 2004.
Steven> I created the patch with the commands:
Steven> LC_ALL=C TZ=GMT diff -u
Steven> classpath-0.08/classpath/doc/vmintegration.te
Mark Wielaard wrote:
Hi,
Hi Mark !
On Thu, 2004-03-25 at 21:19, Guilhem Lavaux wrote:
Some people has reported failures in kaffe with applications trying to
deserialize objects containing final fields. Apparently it is authorized
in the serialization spec but we cannot rely on
java.lang.ref
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
Hi,
If I haven't managed to annoy everybody on this list, you may be interested
to know that a new release of JamVM is out (http://jamvm.sourceforge.net).
This has many, many bug fixes.
My thanks to Mark Wielaard for testing JamVM against Mauve and providing
numerous bug reports, patches, etc
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
Am Montag, 29. März 2004 14:44 schrieb C. Brian Jones:
> On Mon, 2004-03-29 at 01:35, Michael Koch wrote:
> > Am Sonntag, 28. März 2004 21:29 schrieb Etienne Gagnon:
> > > Mark Wielaard wrote:
> > > > Unless running with --force the auto* tools shouldn't override
> > > > these files so normally you
On Mon, 2004-03-29 at 01:35, Michael Koch wrote:
> Am Sonntag, 28. März 2004 21:29 schrieb Etienne Gagnon:
> > Mark Wielaard wrote:
> > > Unless running with --force the auto* tools shouldn't override
> > > these files so normally you won't see any diffs when following the
> > > HACKING instruction
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
Hi Etienne,
I wanna apologize myself for being harsh to you lately on the mailing
lists for this project. I dont meant it hard in any way. I just wanted
to make sure that everyone can agree with the code that gets commited
to the GNU classpath project CVS.
Some changes should really be discus
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
Am Montag, 29. März 2004 09:49 schrieb Stephen Crawley:
> Michael Koch <[EMAIL PROTECTED]> said:
> > I really wonder if this primitive script really works on some
> > non-linux platforms. I will commit an improved version later.
>
> It doesn't necessarily work on linux platforms either. On my mac
21 matches
Mail list logo
