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 [general] unify portable platform types (was Re: svn commit: r634547 [2/2] ...)
Date Tue, 11 Mar 2008 13:22:29 GMT
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<gshimansky@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 <gshimansky@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
>
Mime
View raw message