[55] in java-interest
Re: java-interest-digest V1 #25
daemon@ATHENA.MIT.EDU (Chak Tan)
Fri May 5 14:54:38 1995
From: Chak Tan <tan@ee.rochester.edu>
To: java-interest@java.Eng.Sun.COM
Date: Fri, 5 May 1995 12:18:11 -0400 (EDT)
Hi, just wanted to make some comments regarding the latest digest.
> >From: eichin@mit.edu
> >Date: Thu, 4 May 95 00:36:38 -0400
> >Subject: Re: Decompression Speed
>
> >Interesting. What do you think are the major bottlenecks? Is the Java
> >array model part of the speed difference? (I'm interested in
> >implementing some cryptographic algorithms directly in Java, and it
> >would be useful to know what constructions to avoid...)
>
> Sun's explanation is that it is array bounds and null pointer checking,
> which sounds right. Add to that any inefficiencies introduced in the
> original byte-code compilation, the C code generation and in any
> macros/routines that support the resulting C code, and it's easy see
> how a factor of 5 could be introduced. All of which could probably be
> improved on. I've seen papers on optimizing array bounds checking out
> of loops, but it takes some pretty sophisticated analysis of the code
> to do this safely. Java may need this if actual parity with C is
> needed (I'm not sure that it is).
>
[some text deleted]
>
> - --Th
>
How about doing something like an explicit unsafe module declaration
as in modula-3 so that the compiler can aggressively optimize the
array code, and JavaVM can ignore bounds and null pointer checking? I
realize that the objective of Java is to be as safe as possible for
assimilation of foreign content/code; but a major performance boost
for highly trusted byte-code that's been explicitly marked unsafe (to
warn the client) would be a big win in my book.
>
> From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
> Date: Thu, 4 May 1995 13:55:58 -0700
> Subject: Proposed Java Language Extentions
>
> Hi,
>
> These are the notes on the Java Language meeting of Thursday the 4th of May.
>
[munch]
>
> (2) Introduce Enumerations. Postponed. We could not form a consensus
> on the exact nature of enumerations. It was agreed though that
> in no case enum's should be the equivalent of creating a new type.
> We only considered adding type-less enums which help you declare
> a series of constants with a type and a unique value.
>
First some background seems appropriate. I am implementing an
interactive environment for some simulation code as part of my
dissertation, and I am using Python (we only run SunOS here)
as the runtime environment. During the development of my code, I
decide to build up a foreign objects interface to Python and
enumerations was a subject I had to deal with. This is how I feel
enumerations should behave in an interative environment.
*** warning, this rather long description of my implementation of
enumeration for Python may lull you to sleep :{) ***
In my implementation, enumerations are basically hashtables with a few twist.
Here is an example:
Bits is an enumeration with an associated hashtable, the keys are of a
specific type (C_int), but the values can be any Python object.
This is how you build up your table.
bits[key] = value
where key has to be a C_int Python object and value is any Python object.
Python 1.2 (Apr 18 1995) [GCC 2.6.3]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> from enum import *
>>> bits
<fgnDesc: &7b4b0, flags: 12 = Dy+Boss+, type: C_enum C_int>
>>> bits.keys()
[-2147483648, 1073741824, 1, 2, 4, 256, 8192, 2097152, 65536, 8, 512,
268435456, 16384, 33554432, 4194304, 1024, 131072, 16, 536870912, 128,
1048576, 32768, 4096, 134217728, 16777216, 524288, 64, 2048, 67108864,
8388608, 262144, 32]
>>> bits.values()
['bit32', 'bit31', 'bit1', 'bit2', 'bit3', 'bit9', 'bit14', 'bit22',
'bit17', 'bit4', 'bit10', 'bit29', 'bit15', 'bit26', 'bit23', 'bit11',
'bit18', 'bit5', 'bit30', 'bit8', 'bit21', 'bit16', 'bit13', 'bit28',
'bit25', 'bit20', 'bit7', 'bit12', 'bit27', 'bit24', 'bit19', 'bit6']
>>> bits.dict()
{1: 'bit1', 2: 'bit2', 64: 'bit7', 4: 'bit3', 4194304: 'bit23', 128:
'bit8', 8: 'bit4', 4096: 'bit13', 8388608: 'bit24', 32768: 'bit16',
256: 'bit9', 268435456: 'bit29', 16: 'bit5', 8192: 'bit14', 67108864:
'bit27', 16777216: 'bit25', 65536: 'bit17', 512: 'bit10', 262144:
'bit19', 536870912: 'bit30', 32: 'bit6', 2097152: 'bit22', 2048:
'bit12', 16384: 'bit15', 134217728: 'bit28', 33554432: 'bit26',
131072: 'bit18', 1048576: 'bit21', 1024: 'bit11', 524288: 'bit20',
-2147483648: 'bit32', 1073741824: 'bit31'}
>>>
Now, bits is an enumeration that can be assigned to and accessed.
First you have to initialize bits as compared to building up the
hashtable for bits.
>>> bits.value
Traceback (innermost last):
File "<stdin>", line 1, in ?
AccessError: not initialized
You can only assigned bits a value that's in its table.
>>> bits.value = 'test'
Traceback (innermost last):
File "<stdin>", line 1, in ?
AccessError: item's value not in table
>>> bits.value = 'bit7'
You can ask for the key associate with bits' current value.
>>> bits.key
64
You can also assign bits a key instead of a value, but that's also
check against its hashtable of allowed key/values. (Actually, I
should have presented this first because key access/checking is much
more natural for a hashtable than value access.)
>>> bits.key = 99
Traceback (innermost last):
File "<stdin>", line 1, in ?
AccessError: item's key not in table
Also, remember keys are type checked.
>>> bits.key = 4
Traceback (innermost last):
File "<stdin>", line 1, in ?
AccessError: item's key not in table
Specifically, the keys are of type C_int. I just happen to have a
C_int variable handy which was imported and initialized (to 4) as part
of the enum import.
>>> a = test.int
>>> a
4
>>> bits.key = a
>>> bits.value
'bit3'
Actually, bits is a special type of enumeration because the keys are
an integral type. Thus, bits can also be used to implement bit sets.
In this case, the mask() method accepts any integral type and masks
out each bit of the integral value to generate a key. For instance,
>>> bits.mask(1111)
['bit1', 'bit2', 'bit3', 'bit5', 'bit7', 'bit11']
There are also other misc methods for enumerations.
>>> bits.__methods__
['cast', 'del_key', 'del_value', 'dict', 'get_key', 'keys', 'mask',
'new', 'values']
For example,
>>> bits.get_key('bit7')
64
>>>
>
> (7) Instanceof and type Coercion. Postponed. It turns out that
> you often write code like:
>
> if (x instanceof Foo) {
> Foo foox = (Foo)x;
> ...
> }
>
> It would be nice if there was some construct where you could
> test if x is an instance of Foo and then use it as a Foo
> without having to cast it. We could not agree on a good syntax
> that would have little impact on the language and the runtime.
>
[munch]
Disclaimer:
I have no idea how this syntax would impact the language and runtime.
How about:
with (x instanceof Foo) {
x.FooStuff = 1;
...
}
>
> Please feel free to send in your comments.
>
> Have fun,
>
> Arthur van Hoff (avh@eng.sun.com)
> http://java.sun.com/people/avh/
> Sun Microsystems Inc, M/S UPAL02-301,
> 100 Hamilton Avenue, Palo Alto CA 94301, USA
> Tel: +1 415 473 7242, Fax: +1 415 473 7104
>
>
> ------------------------------
>
> End of java-interest-digest V1 #25
> **********************************
>
>
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
