harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [modules] classloader/jit interface
Date Fri, 24 Jun 2005 21:55:54 GMT

On Jun 24, 2005, at 5:47 PM, Rodrigo Kumpera wrote:

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

How would that work?

geir

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

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message