classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Classpath build process and VM-specific issues


From: Mark Wielaard
Subject: Re: Classpath build process and VM-specific issues
Date: Mon, 29 Mar 2004 09:01:43 +0200

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 implementation in case it may add something useful. This is
> just one data point and surely these reasons don't apply universally.

Thanks. The question indeed implied that I was interested in more then
just one Compiler/Runtime case.

> - 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.

It helps immensely with documenting the fact what is/isn't VM-specific.
Or could be. It also help much in providing fallback java+JNI/POSIX
implementations when possible. Sometimes it is just an hint that the
functionality could be optimized by a smart compiler/runtime
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, but
maybe it just won't happen.

> - I used the type byte[] for all vmData fields.

I am now more or less convinced that in some cases we should even mark
it as 'Object'. Again marking it as VMWhatever I had hoped that the
compiler/VM would easily be able to handle it specially. See RawData in
gcj.

> - I prefer to avoid the extra method call overhead for important
>    methods like Object.wait() imposed by the VMFoo split. In Classpath
>    every Object.wait() requires calling VMObject.wait(). That makes
>    the code separation cleaner but doesn't make implementation any
>    easier - it's just as easy to implement Object.wait() as a native
>    method as it is to implement VMObject.wait() as a native method.

See above. And the environment is always free to overwrite specific
special cases (like Object and Class will almost always be I guess).

> - 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 duplicated
>    elsewhere.

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 subtle issues with just doing everything as wrappers
over Object.wait()/notify().

> - I folded VMThrowable into Throwable to get rid of VMThrowable.
>    Same reasons as mentioned above.

Would it be possible for your compiler to detect these special cases and
inline at compile time?

> - These bugs (not fixed in Classpath 0.07):
>    http://savannah.gnu.org/bugs/?func=detailitem&item_id=6938
>    http://savannah.gnu.org/bugs/?func=detailitem&item_id=7084

Yes, both should be fixed ASAP (also not fixed in 0.08).
Thanks for providing patches. (Put on my list of things to review and
apply. Together with your VMProcess implementation... Sorry, need more
then 24 hours a day it seems.)

> - Classpath's reflection implementation is/was incomplete and
>    required modifications to work.

Lots of ideas there so I hope the situation will be better for 0.09.

> Hope these don't sound like complaints - using Classpath has worked
> out great and I'm very appreciative of it!!

You remarks were very appreciated.
Sorry for still not having tried out JC.
But for everyone on this list I would recommend reading at least the
manual which has some great insights into VM/Compiler/Runtime issues:
http://jcvm.sourceforge.net/doc/jc.html

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]