You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexey Varlamov <al...@gmail.com> on 2008/03/11 14:22:29 UTC
[general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Guys,
Thanks for raising this theme. I'd like to generalize the issue, as we
have too much duplicating type definitions (in DRLVM in particular),
mixing both in inter-component interfaces and in implementations. This
is confusing and inconvenient, I suggest we adopt a single type system
in all components. So now we have:
1) portlib types (BOOLEAN, UDATA/IDATA, I_8/U_8 ... U_64/I_64) -
is the sole type system allowed in classlib now and used for public interfaces.
2) DRLVM types (Boolean, POINTER_SIZE_INT/POINTER_SIZE_SINT,
int8/uint8 ... int64/uint64) -
is widely used in DRLVM. I have to admit, the naming is inconsistent
and clumsy, sometimes provoking use of alternative definitions like
"int_ptr".
3) Scattered definitions to complement C++ type system like "int_ptr",
etc. I assume there is a common agreement to keep export interfaces
C-compliant so no way to rely on C++ specific types.
4) JNI types (jboolean/jint/jlong/jobject etc);
Well, I added the JNI types only because Alexei suggested to reuse
them. IMO they are not suitable for general adoption in C/C++ code:
- they are incomplete, e.g. no unsigned types and no platform-size int type;
- the jni_types header defines other non-relevant types specific for
JNI, and we should avoid cluttering general namespace.
5) APR provides a set of primitive types, yet it is incomplete for JVM building.
So the most reasonable way to unify the type systems is to switch
(DRLVM's code) to types provided by classlib's portlibrary. What do
you think?
--
Alexey
08.03.08, Gregory Shimansky<gs...@apache.org> написал(а):
> On 8 марта 2008 Ilya Berezhniuk wrote:
> > Gregory,
> >
> > Yes, Boolean is a synthetic type, but it's defined as 'unsigned'.
> > UDATA represents BOOLEAN type which is used in few places only for
> > HyThread compatibility.
>
> Ah I see. I've confused these boolean definitions. I am starting to think
> we've got by far too many different booleans... :)
>
> > I agree with some Alexei's thoughts: in pure C interface we can use
> > C-style return values, i.e. use 0 as success (for boolean result) and
> > 0 for failure (when a pointer should be returned).
> >
> > Thanks,
> > Ilya.
> >
> > 2008/3/8, Gregory Shimansky <gs...@apache.org>:
> > > On 7 марта 2008 Mikhail Fursov wrote:
> > > > Alexey,
> > > > there is a problem with this commit.
> > > > Some of methods that returns Boolean (that is 'unsigned') are
> > > > described as 'bool' in vm_interface.h
> > > > It's not the same and causes problems. For example I found that H2092
> > > > fails now in debug mode on Linux because of 'field_is_volatile'
> > > > method.
> > >
> > > I see 3 different problems with 3 different used approaches
> > >
> > > 1. bool is a C++ type an cannot be used in a pure C interface. Don't
> > > tell me about extended C standards. Period.
> > > 2. Boolean is a synthetic type which is actually UDATA that corresponds
> > > to POINTER_SIZE_INT and this means by far unoptimal decision for a type
> > > that holds a single meaning bit.
> > > 3. jboolean is a type defined for Java only.
> > >
> > > As long as we work on Java jboolean is the most universal definition
> > > since it is actually specified. In case JIT code may be reused for other
> > > code we might invent jitboolean to be equal in definition to jboolean
> > > both in spec and code. I would vote for such approach.
> > >
> > > --
> > >
> > > Gregory
>
>
>
> --
> Gregory
>
Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Posted by Alexei Fedotov <al...@gmail.com>.
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
<al...@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 <al...@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
> > <al...@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 <pm...@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 <al...@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 <xi...@gmail.com> wrote:
> > > > > > On Tue, Mar 11, 2008 at 11:00 PM, Alexey Varlamov
> > > > > >
> > > > > > <al...@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
Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Posted by Alexey Varlamov <al...@gmail.com>.
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 <al...@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
> <al...@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 <pm...@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 <al...@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 <xi...@gmail.com> wrote:
> > > > > On Tue, Mar 11, 2008 at 11:00 PM, Alexey Varlamov
> > > > >
> > > > > <al...@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
>
Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Posted by Alexei Fedotov <al...@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
<al...@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 <pm...@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 <al...@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 <xi...@gmail.com> wrote:
> > > > On Tue, Mar 11, 2008 at 11:00 PM, Alexey Varlamov
> > > >
> > > > <al...@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
Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Posted by Alexey Varlamov <al...@gmail.com>.
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 <pm...@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 <al...@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 <xi...@gmail.com> wrote:
> > > On Tue, Mar 11, 2008 at 11:00 PM, Alexey Varlamov
> > >
> > > <al...@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
>
Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Posted by Pavel Pervov <pm...@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 <al...@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 <xi...@gmail.com> wrote:
> > On Tue, Mar 11, 2008 at 11:00 PM, Alexey Varlamov
> >
> > <al...@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
Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Posted by Alexei Fedotov <al...@gmail.com>.
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 <xi...@gmail.com> wrote:
> On Tue, Mar 11, 2008 at 11:00 PM, Alexey Varlamov
>
> <al...@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
Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Tue, Mar 11, 2008 at 11:00 PM, Alexey Varlamov
<al...@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
Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Posted by Alexey Varlamov <al...@gmail.com>.
> 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
Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Posted by Xiao-Feng Li <xi...@gmail.com>.
On Tue, Mar 11, 2008 at 9:22 PM, Alexey Varlamov
<al...@gmail.com> wrote:
> Guys,
>
> Thanks for raising this theme. I'd like to generalize the issue, as we
> have too much duplicating type definitions (in DRLVM in particular),
> mixing both in inter-component interfaces and in implementations. This
> is confusing and inconvenient, I suggest we adopt a single type system
> in all components. So now we have:
>
> 1) portlib types (BOOLEAN, UDATA/IDATA, I_8/U_8 ... U_64/I_64) -
> is the sole type system allowed in classlib now and used for public interfaces.
> 2) DRLVM types (Boolean, POINTER_SIZE_INT/POINTER_SIZE_SINT,
> int8/uint8 ... int64/uint64) -
> is widely used in DRLVM. I have to admit, the naming is inconsistent
> and clumsy, sometimes provoking use of alternative definitions like
> "int_ptr".
> 3) Scattered definitions to complement C++ type system like "int_ptr",
> etc. I assume there is a common agreement to keep export interfaces
> C-compliant so no way to rely on C++ specific types.
> 4) JNI types (jboolean/jint/jlong/jobject etc);
> Well, I added the JNI types only because Alexei suggested to reuse
> them. IMO they are not suitable for general adoption in C/C++ code:
> - they are incomplete, e.g. no unsigned types and no platform-size int type;
> - the jni_types header defines other non-relevant types specific for
> JNI, and we should avoid cluttering general namespace.
> 5) APR provides a set of primitive types, yet it is incomplete for JVM building.
>
> So the most reasonable way to unify the type systems is to switch
> (DRLVM's code) to types provided by classlib's portlibrary. What do
> you think?
Consistent type definition is definitely good. Btw, what's the
POINTER_SIZE_INT counterpart in port library?
Thanks,
xiaofeng
> --
> Alexey
>
> 08.03.08, Gregory Shimansky<gs...@apache.org> написал(а):
> > On 8 марта 2008 Ilya Berezhniuk wrote:
> > > Gregory,
> > >
> > > Yes, Boolean is a synthetic type, but it's defined as 'unsigned'.
> > > UDATA represents BOOLEAN type which is used in few places only for
> > > HyThread compatibility.
> >
> > Ah I see. I've confused these boolean definitions. I am starting to think
> > we've got by far too many different booleans... :)
> >
> > > I agree with some Alexei's thoughts: in pure C interface we can use
> > > C-style return values, i.e. use 0 as success (for boolean result) and
> > > 0 for failure (when a pointer should be returned).
> > >
> > > Thanks,
> > > Ilya.
> > >
> > > 2008/3/8, Gregory Shimansky <gs...@apache.org>:
> > > > On 7 марта 2008 Mikhail Fursov wrote:
> > > > > Alexey,
> > > > > there is a problem with this commit.
> > > > > Some of methods that returns Boolean (that is 'unsigned') are
> > > > > described as 'bool' in vm_interface.h
> > > > > It's not the same and causes problems. For example I found that H2092
> > > > > fails now in debug mode on Linux because of 'field_is_volatile'
> > > > > method.
> > > >
> > > > I see 3 different problems with 3 different used approaches
> > > >
> > > > 1. bool is a C++ type an cannot be used in a pure C interface. Don't
> > > > tell me about extended C standards. Period.
> > > > 2. Boolean is a synthetic type which is actually UDATA that corresponds
> > > > to POINTER_SIZE_INT and this means by far unoptimal decision for a type
> > > > that holds a single meaning bit.
> > > > 3. jboolean is a type defined for Java only.
> > > >
> > > > As long as we work on Java jboolean is the most universal definition
> > > > since it is actually specified. In case JIT code may be reused for other
> > > > code we might invent jitboolean to be equal in definition to jboolean
> > > > both in spec and code. I would vote for such approach.
> > > >
> > > > --
> > > >
> > > > Gregory
> >
> >
> >
> > --
> > Gregory
> >
>
--
http://xiao-feng.blogspot.com
Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Posted by Alexey Varlamov <al...@gmail.com>.
2008/3/11, Pavel Pervov <pm...@gmail.com>:
> +1 from me with the exception of BOOLEAN. Can we make it 32-bit always
> and not sizeof(void*)? VME gurus opinions?
Ah yes, it is fixed size in portlib:
typedef U_32 BOOLEAN;
I believe there is no use case for platform-size boolean :)
>
> Pavel.
>
> On 3/11/08, Alexey Varlamov <al...@gmail.com> wrote:
> > Guys,
> >
> > Thanks for raising this theme. I'd like to generalize the issue, as we
> > have too much duplicating type definitions (in DRLVM in particular),
> > mixing both in inter-component interfaces and in implementations. This
> > is confusing and inconvenient, I suggest we adopt a single type system
> > in all components. So now we have:
> >
> > 1) portlib types (BOOLEAN, UDATA/IDATA, I_8/U_8 ... U_64/I_64) -
> > is the sole type system allowed in classlib now and used for public interfaces.
> > 2) DRLVM types (Boolean, POINTER_SIZE_INT/POINTER_SIZE_SINT,
> > int8/uint8 ... int64/uint64) -
> > is widely used in DRLVM. I have to admit, the naming is inconsistent
> > and clumsy, sometimes provoking use of alternative definitions like
> > "int_ptr".
> > 3) Scattered definitions to complement C++ type system like "int_ptr",
> > etc. I assume there is a common agreement to keep export interfaces
> > C-compliant so no way to rely on C++ specific types.
> > 4) JNI types (jboolean/jint/jlong/jobject etc);
> > Well, I added the JNI types only because Alexei suggested to reuse
> > them. IMO they are not suitable for general adoption in C/C++ code:
> > - they are incomplete, e.g. no unsigned types and no platform-size int type;
> > - the jni_types header defines other non-relevant types specific for
> > JNI, and we should avoid cluttering general namespace.
> > 5) APR provides a set of primitive types, yet it is incomplete for JVM building.
> >
> > So the most reasonable way to unify the type systems is to switch
> > (DRLVM's code) to types provided by classlib's portlibrary. What do
> > you think?
> >
> > --
> > Alexey
> >
> > 08.03.08, Gregory Shimansky<gs...@apache.org> написал(а):
> > > On 8 марта 2008 Ilya Berezhniuk wrote:
> > > > Gregory,
> > > >
> > > > Yes, Boolean is a synthetic type, but it's defined as 'unsigned'.
> > > > UDATA represents BOOLEAN type which is used in few places only for
> > > > HyThread compatibility.
> > >
> > > Ah I see. I've confused these boolean definitions. I am starting to think
> > > we've got by far too many different booleans... :)
> > >
> > > > I agree with some Alexei's thoughts: in pure C interface we can use
> > > > C-style return values, i.e. use 0 as success (for boolean result) and
> > > > 0 for failure (when a pointer should be returned).
> > > >
> > > > Thanks,
> > > > Ilya.
> > > >
> > > > 2008/3/8, Gregory Shimansky <gs...@apache.org>:
> > > > > On 7 марта 2008 Mikhail Fursov wrote:
> > > > > > Alexey,
> > > > > > there is a problem with this commit.
> > > > > > Some of methods that returns Boolean (that is 'unsigned') are
> > > > > > described as 'bool' in vm_interface.h
> > > > > > It's not the same and causes problems. For example I found that H2092
> > > > > > fails now in debug mode on Linux because of 'field_is_volatile'
> > > > > > method.
> > > > >
> > > > > I see 3 different problems with 3 different used approaches
> > > > >
> > > > > 1. bool is a C++ type an cannot be used in a pure C interface. Don't
> > > > > tell me about extended C standards. Period.
> > > > > 2. Boolean is a synthetic type which is actually UDATA that corresponds
> > > > > to POINTER_SIZE_INT and this means by far unoptimal decision for a type
> > > > > that holds a single meaning bit.
> > > > > 3. jboolean is a type defined for Java only.
> > > > >
> > > > > As long as we work on Java jboolean is the most universal definition
> > > > > since it is actually specified. In case JIT code may be reused for other
> > > > > code we might invent jitboolean to be equal in definition to jboolean
> > > > > both in spec and code. I would vote for such approach.
> > > > >
> > > > > --
> > > > >
> > > > > Gregory
> > >
> > >
> > >
> > > --
> > > Gregory
> > >
> >
>
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>
Re: [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Posted by Pavel Pervov <pm...@gmail.com>.
+1 from me with the exception of BOOLEAN. Can we make it 32-bit always
and not sizeof(void*)? VME gurus opinions?
Pavel.
On 3/11/08, Alexey Varlamov <al...@gmail.com> wrote:
> Guys,
>
> Thanks for raising this theme. I'd like to generalize the issue, as we
> have too much duplicating type definitions (in DRLVM in particular),
> mixing both in inter-component interfaces and in implementations. This
> is confusing and inconvenient, I suggest we adopt a single type system
> in all components. So now we have:
>
> 1) portlib types (BOOLEAN, UDATA/IDATA, I_8/U_8 ... U_64/I_64) -
> is the sole type system allowed in classlib now and used for public interfaces.
> 2) DRLVM types (Boolean, POINTER_SIZE_INT/POINTER_SIZE_SINT,
> int8/uint8 ... int64/uint64) -
> is widely used in DRLVM. I have to admit, the naming is inconsistent
> and clumsy, sometimes provoking use of alternative definitions like
> "int_ptr".
> 3) Scattered definitions to complement C++ type system like "int_ptr",
> etc. I assume there is a common agreement to keep export interfaces
> C-compliant so no way to rely on C++ specific types.
> 4) JNI types (jboolean/jint/jlong/jobject etc);
> Well, I added the JNI types only because Alexei suggested to reuse
> them. IMO they are not suitable for general adoption in C/C++ code:
> - they are incomplete, e.g. no unsigned types and no platform-size int type;
> - the jni_types header defines other non-relevant types specific for
> JNI, and we should avoid cluttering general namespace.
> 5) APR provides a set of primitive types, yet it is incomplete for JVM building.
>
> So the most reasonable way to unify the type systems is to switch
> (DRLVM's code) to types provided by classlib's portlibrary. What do
> you think?
>
> --
> Alexey
>
> 08.03.08, Gregory Shimansky<gs...@apache.org> написал(а):
> > On 8 марта 2008 Ilya Berezhniuk wrote:
> > > Gregory,
> > >
> > > Yes, Boolean is a synthetic type, but it's defined as 'unsigned'.
> > > UDATA represents BOOLEAN type which is used in few places only for
> > > HyThread compatibility.
> >
> > Ah I see. I've confused these boolean definitions. I am starting to think
> > we've got by far too many different booleans... :)
> >
> > > I agree with some Alexei's thoughts: in pure C interface we can use
> > > C-style return values, i.e. use 0 as success (for boolean result) and
> > > 0 for failure (when a pointer should be returned).
> > >
> > > Thanks,
> > > Ilya.
> > >
> > > 2008/3/8, Gregory Shimansky <gs...@apache.org>:
> > > > On 7 марта 2008 Mikhail Fursov wrote:
> > > > > Alexey,
> > > > > there is a problem with this commit.
> > > > > Some of methods that returns Boolean (that is 'unsigned') are
> > > > > described as 'bool' in vm_interface.h
> > > > > It's not the same and causes problems. For example I found that H2092
> > > > > fails now in debug mode on Linux because of 'field_is_volatile'
> > > > > method.
> > > >
> > > > I see 3 different problems with 3 different used approaches
> > > >
> > > > 1. bool is a C++ type an cannot be used in a pure C interface. Don't
> > > > tell me about extended C standards. Period.
> > > > 2. Boolean is a synthetic type which is actually UDATA that corresponds
> > > > to POINTER_SIZE_INT and this means by far unoptimal decision for a type
> > > > that holds a single meaning bit.
> > > > 3. jboolean is a type defined for Java only.
> > > >
> > > > As long as we work on Java jboolean is the most universal definition
> > > > since it is actually specified. In case JIT code may be reused for other
> > > > code we might invent jitboolean to be equal in definition to jboolean
> > > > both in spec and code. I would vote for such approach.
> > > >
> > > > --
> > > >
> > > > Gregory
> >
> >
> >
> > --
> > Gregory
> >
>
--
Pavel Pervov,
Intel Enterprise Solutions Software Division