harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Date Wed, 12 Mar 2008 08:02:32 GMT
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 <pmcfirst@gmail.com>:
> 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