Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4112810

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



    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:


      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

      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
      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 */


          Issue Links



              duke J. Duke (Inactive)
              jbenoit Jonathan Benoit (Inactive)
              0 Vote for this issue
              0 Start watching this issue