harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Date Wed, 12 Mar 2008 10:07:59 GMT
I like these type names: they are pretty short. I believe a
replacement of POINTER_SIZE_INT is the best thing to start with. From
the other side there are some things about portlib I don't understand,
namely, all calls have to go via a virtual table of portlib functions.
Why it is done in this way?



On Wed, Mar 12, 2008 at 12:42 PM, Alexey Varlamov
<alexey.v.varlamov@gmail.com> wrote:
> 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 <alexei.fedotov@gmail.com>:
>
>
> > Alexey,
>  > Which conventions have you decided to use for intercomponent interfaces?
>  >
>  > Thanks!
>  >
>  > On Wed, Mar 12, 2008 at 11:02 AM, Alexey Varlamov
>  > <alexey.v.varlamov@gmail.com> 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 <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
>  > >  >
>  > >
>  >
>  >
>  >
>  > --
>  > With best regards,
>  > Alexei
>  >
>



-- 
With best regards,
Alexei

Mime
View raw message