Going 64bit and beyond

Constantine Plotnikov


Table of Contents

Problem statement
Possible solutions
Size type
Add size type parameter to collections.

Problem statement

One of the problems real implementation should solve is support 64-bit architectures. AMD and possibly Intel are going to introduce 64 bit processor on desktop and they are already 64bit are on modern servers.

To support 64bit architectures there will be needed changes to collections to handle them. There are following changes are needed[1]:

  • Support indexing of > 2GB collections.

  • Support 64 bit hash codes.

We could also consider later support of 128 bits architectures, and the best solution should work with them too.

Possible solutions

Size type

One of variants is to introduce size type. This type will be native for platform. getHashCode() code has to evaluate to this type.

Advantages

  • Type will resolve at class loading.

  • Hashcode calculation algorithm could be chaged.

Disadvantages

  • Hashcode will not be portable between runtimes with different bitness.

  • Assumptions that size will fit some predefinied constant will be broken, it could cause problem with storing and retriving data.

Add size type parameter to collections.

In this variant there will be size paramenter to collections. So there could be List[String,Int64] and List[String,Int16].

Advantages

  • For embeded solution it will be possible to use collections with little size like 16 bits.

Disadvantages

  • Hashcode does not fit the scheme.

  • Size fixing proxies will need to be provided



[1] This problem is specific to strongly typed desing of language. Weakly typed language E will not face this problem.