Those adopted in classlib (working_classlib\modules\portlib\src\main\native\include\shared\hycomp.h ): BOOLEAN, UDATA/IDATA, I_8/U_8 ... U_64/I_64
-- Alexey 2008/3/12, Alexei Fedotov <[EMAIL PROTECTED]>: > Alexey, > Which conventions have you decided to use for intercomponent interfaces? > > Thanks! > > On Wed, Mar 12, 2008 at 11:02 AM, Alexey Varlamov > <[EMAIL PROTECTED]> wrote: > > Thanks Pavel, this is a clear statement which I'm also advocating. > > Any implementation is free to use most suitable types internally, but > > there should be an agreement on types used in public interfaces. OS > > layer is mostly irrelevant here. > > So I see no objections to the suggested route, will start fixing > > VM-JIT interface soon. > > > > -- > > Alexey > > > > > > 2008/3/11, Pavel Pervov <[EMAIL PROTECTED]>: > > > > > > > Alexei, > > > > > > I'd like to add my little coin here. > > > > > > We should use corresponding types in the places where they apply best. > > > JNI type system is a kind of external to Harmony. > > > > > > Probably, we should establish 1-1 type correspondense between JNI type > > > system and VM type system and only use JNI types in JNI implementation > > > itself (including helper functions) and convert these types as we > > > cross "JNI implementation" boundary. The same holds true for JVMTI > > > which shares type system with JNI. > > > > > > The same for OS layer. OS specific types shouldn't (and I hope won't) > > > be visible outside "porting layer". > > > > > > The rest of VM+class library can have single consistent type system > > > which is converted to "outside world" on interface boundaries of > > > runtime. > > > > > > WBR, > > > Pavel. > > > > > > On 3/11/08, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > > > > Alexey, > > > > This is a very interesting thread. Let me give more examples of JNI > > > > pro and contra. > > > > > > > > * JNI is good for implementation of class library native functions, > > > > because their arguments are supplied in JNI form. > > > > * JNI is a good type system for java-based tools, plug-ins, etc. > > > > * JNI is desired to code java specific things like work with > > > > local/global references, class loading, finalization, jvmti. We > > > > usually put such staff in vmcore. (Class parsing may be an exception > > > > because even specification operates in a different notation. From the > > > > other side I believe we should build our class parser on the top of > > > > something like ASN.1 and get rid of this problem.) > > > > > > > > As for a current state of our code, I don't think JNI types are good > > > > for JIT, Encoder, GC, and an execution manager. They consistently use > > > > a different type system and I dream they become usable for other > > > > projects, so no need to force them being java specific. > > > > > > > > As for a porting layer, it consists of two types of functions: > > > > * OS and library calls: I believe we should just use *nix APIs and > > > > types instead of wrappers and re-implement them for Windows like > > > > Cygwin does. First, this is now possible, and second, this just gives > > > > us less wrappers. > > > > * Assembler wrappers (fences, atomics, monitor instructions, etc): > > > > they are too far from java to use JNI. From the other side > > > > java.util.concurent mandates JNI atomics, so sometimes JNI is good > > > > even here. > > > > > > > > What do you think? > > > > > > > > > > > > On Tue, Mar 11, 2008 at 6:06 PM, Xiao-Feng Li <[EMAIL PROTECTED]> > > wrote: > > > > > On Tue, Mar 11, 2008 at 11:00 PM, Alexey Varlamov > > > > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > Consistent type definition is definitely good. Btw, what's the > > > > > > > POINTER_SIZE_INT counterpart in port library? > > > > > > > > > > > > AFAIU > > > > > > POINTER_SIZE_INT == UDATA > > > > > > POINTER_SIZE_SINT == IDATA > > > > > > > > > > > > > > > > I see. Thanks. > > > > > > > > > > -xiaofeng > > > > > > > > > > > > > > > > > > > > -- > > > > > http://xiao-feng.blogspot.com > > > > > > > > > > > > > > > > > > > > > -- > > > > With best regards, > > > > Alexei > > > > > > > > > > > > > -- > > > Pavel Pervov, > > > Intel Enterprise Solutions Software Division > > > > > > > > > -- > With best regards, > Alexei >
