harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm][magic] New Magic features proposal.
Date Tue, 23 Jan 2007 15:21:14 GMT
On 1/23/07, Robin Garner <robin.garner@anu.edu.au> wrote:
> > On 1/22/07, Robin Garner <robin.garner@anu.edu.au> wrote:
> >>
> >> Couldn't you achieve exactly the same effect by using an annotation to
> >> mark the called native method ?
> >>
> >> Such as
> >>
> >>   @FastNative
> >>   public native fastNativeMethod(args...);
> >>
> >
> > Robin,
> > I think such an annotation is a good idea for native methods without GC.
> > If GC enumeration is possible from within a native method call (arbitrary
> > 3rd party JNI method), we have to create m2n stub.
>
> Of course.  I am implicitly assuming that fast native calls are a feature
> that only the VM will ever use (Magic is not something a user application
> should be allowed to call).
>
> I still don't see why there would be a problem generating a specific
> calling sequence automatically (eg inserting the m2n stub) based on an
> annotation on the target method, rather than encoding it directly in new
> Magic calls.  I guess I'm assuming that whether GC is possible or not
> depends on whether the callee method is marked @Uninterruptible, and that
> the compiler can generate the method call accordingly.
>

Based on my prior experience with M2N frame work, I have the same
feeling that compiler instrinsic might be able to deal with fast
native call (except some corner cases where very special calling
convention ect. is used, e.g., the native method itself is a
hand-written asm code sequence.)

Probably the compiler instrinsic semantics can be expressed with Java
Magics, then they are just the same thing from different viewpoints.

Thanks,
xiaofeng

> Regards,
> Robin
>
> > --
> > Mikhail Fursov
> >
>
>
>

Mime
View raw message