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
|