harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Date Tue, 11 Mar 2008 15:53:49 GMT
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 <alexei.fedotov@gmail.com> 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 <xiaofeng.li@gmail.com> wrote:
> > On Tue, Mar 11, 2008 at 11:00 PM, Alexey Varlamov
> >
> > <alexey.v.varlamov@gmail.com> 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

Mime
View raw message