(porting) suggested improvements to make VM easier to port (powers of two)

Licensee made a minimal effort to produce source that is more portable.
In several cases, however, the effort to do so was too large and the change will
only work on our platform. In other cases, licensee kept the code in the shared
directory instead of moving it into the platform specific directory. Obviously
these changes will need much more work before they can be released.

Portability, "Power of 2" explanation:
--------------------------------------
Places in the shared directory assume that the platform's native word size is a
power of 2. That is, sizeof(int) is 4 or 8. On the ClearPath HMP NX (A Series)
platform, the native word size is 6 bytes. A double word is 12 bytes. So
sizeof(int) is 6 and sizeof(long double) is 12. Note that our pointers are
always offsets in terms of bytes (the ClearPath HMP IX or 2200 Series has
pointers that are word offsets or byte offsets). This means that :

1) constant values like 4 and 8 need to be sizeof(<type>) instead.

2) pointers to double-word align objects in the heap may not have their low
three bits be 0. To ensure that the low three bits in the pointer are zero, the
object has to be aligned to a multiple of 24 bytes (an obvious waste of space).
Ideally, the location of the bits should be defined by macros in the platform
headers. We have spare bits elsewhere in the word that could be used, allow
objects to be word aligned only.

3) Adding 3 and then ANDing (&) a mask with the low two bits off does not align
to the next word boundary Ditto for adding 7 and ANDing a mask with the low
three bits off for double word alignment.. In fact, ANDing is not usable for
alignment on our platform and a div (/) or mod (%) has to be used.

4) Shifting a pointer left 3 bits does not reduce it to a OBJECTGRAIN offset. A
division is required. Ditto for computhing which page an address is in.

5) The size of a scalar type can still be represented in a two bit field
(T_SIZEFIELD), but that representation is not log2 of the size. For our
platform, the sizes are:
char 1
short 6
int 6
double 12

6) Hardware page sizes are not a power of 2. In fact, no sizes are a power of
2.

Specific example/code fix to follow -
In the following patch listing, "L" refers to the left path which is original
file from JavaSoft and "R" refers to the right path which is our modified file.

This bug fix is actually two in one - first a Power of 2 change is
in line L4792. Second, min is set just a few lines above in
hpool = sysCommitMem(hpool, min_request, &min);
based on the value of hpool. If we change the value of 'hpool', i.e.
round it up to the nearest HANDLEGRAIN, then min is too large and needs
to shrink. This probably does not happen on your system because hpool
is probably already HANDLEGRAIN aligned. It is not on our system and
min was ending up too large.

Comparison of J:\JAE1_2T\src\share\javavm\runtime\GC.C and
J:\PC\SHARE\javavm\runtime\GC.C
Version 1.206

----------------------------------------------------- BUG FIX
L4791 hpool = (unsigned char *)
L4792 (((int) hpool + HANDLEGRAIN-1) & ~(HANDLEGRAIN-1));
L4793 hpoollimit = hpool + min;

R4801 hpoollimit = hpool + min; /* srb - remove rounding from min */
R4802 hpool = (unsigned char *)
R4803 ((((int) hpool + HANDLEGRAIN-1)/HANDLEGRAIN)*HANDLEGRAIN);/*SRB*/
R4804 min = hpoollimit - hpool; /* srb - remove rounding from min */