harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo Kumpera <kump...@gmail.com>
Subject Re: [modules] classloader/jit interface
Date Fri, 24 Jun 2005 21:47:29 GMT
If the API is meant to be language agnostic, it's just a bunch of
constants and a function vector. This should provide enouth to build a
better layer for each language.

The API between a Java JITer and a C JVM should be coarse grained
since cross-language calls are slow. ORP defines a very nice C++ only
interface, but I doubt it would work well for the C++ <-> Java
scenario.

This might be too 80's, but a good interface can be well defined in
terms of functions, structs and constants. It will work just fine for
C/C++ and would not be that painfull or slow to use from Java (or
whatever comes into our mind).

Or we can use IDL and let it be object oriented.

Rodrigo

On 6/24/05, Geir Magnusson Jr. <geirm@apache.org> wrote:
> 
> On Jun 24, 2005, at 5:17 PM, Weldon Washburn wrote:
> 
> > On 6/23/05, Geir Magnusson Jr. <geirm@apache.org> wrote:
> >
> >
> >> Where is code we can start examining?  What do the the java-on-java
> >> implementations do?
> >>
> >> geir
> >>
> >>
> >
> > Geir,
> > I can't talk about code just yet.
> 
> 
> I know, but I'm going to taunt you anyway!  Taunt!
> 
> Seriously, how about referring us to code in ORP at sourceforge?
> 
> > But I think we can at least get
> > started on the basic, low controversy APIs.  For example, the access
> > and property flags defined in the class file format are straight
> > forward boolean values.  While the access/property flags may be
> > extended, it is unlikely that basic notions such as public/private
> > access would ever be removed.  Below is a first stab at the API to
> > retrieve the values contained in internal classloader data structures.
> >  Its understood that the JIT won't use all of the below APIs.  For
> > example, some of the access properties issues are dealt with during
> > resolution and not by the jit.  I used the java 1.5 version of Chapter
> > 3 of the Java Virtual Machine Spec.
> >
> 
> > Comment/questions are appreciated.
> >
> >     Thanks
> >         Weldon
> >
> > Class access and property modifiers (table 4.1)
> > bool Class::is_public();        // ACC_PUBLIC
> > bool Class::is_final();        // ACC_FINAL
> > bool Class::is_super();        // ACC_SUPER
> > bool Class::is_interface();    // ACC_INTERFACE
> > bool Class::is_abstract();    // ACC_ABSTRACT
> > bool Class::is_synthetic();    // ACC_SYNTHETIC
> > bool Class::is_annotation();    // ACC_ANNOTATION
> > bool Class::is_enum();        // ACC_ENUM
> >
> > Field access and property flags (table 4.4)
> > bool Field::is_public();        // ACC_PUBLIC
> > bool Field::is_private();        // ACC_PRIVATE
> > bool Field::is_protected();    // ACC_PROTECTED
> > bool Field::is_static();        // ACC_STATIC
> > bool Field::is_final();        // ACC_FINAL
> > bool Field::is_volatile();    // ACC_VOLATILE
> > bool Field::is_transient();    // ACC_TRANSIENT
> > bool Field::is_synthetic();    // ACC_SYNTHETIC
> > bool Field::is_enum();        // ACC_ENUM
> >
> > Method access and property flags (table 4.5)
> > bool Method::is_public();    // ACC_PUBLIC
> > bool Method::is_private();    // ACC_PRIVATE
> > bool Method::is_protected();    // ACC_PROTECTED
> > bool Method::is_static();    // ACC_STATIC
> > bool Method::is_final();        // ACC_FINAL
> > bool Method::is_synchronized();     // ACC_SYNCHRONIZED
> > bool Method::is_bridge();    // ACC_BRIDGE
> > bool Method::is_varargs();    // ACC_VARARGS
> > bool Method::is_native();    // ACC_NATIVE
> > bool Method::is_abstract();    // ACC_ABSTRACT
> > bool Method::is_strict();    // ACC_STRICT
> > boot Method::is_synthetic();            // ACC_SYNTHETIC
> >
> 
> That's pretty non-controversial :)
> 
> So this API is really for the classes Method, Field and Class, rather
> than a bigger C API.  Does this make it harder for other languages to
> use or implement?  (I have to admit it's going to take a few to start
> thinking in C again...)
> 
> geir
> 
> --
> Geir Magnusson Jr                                  +1-203-665-6437
> geirm@apache.org
> 
> 
>

Mime
View raw message