[infinispan-issues] [JBoss JIRA] (ISPN-8521) Off-heap addresses could be stored as int instead of long

[Dan Berindei (JIRA)]

Dan Berindei created ISPN-8521:
----------------------------------

             Summary: Off-heap addresses could be stored as int instead of long
                 Key: ISPN-8521
                 URL: https://issues.jboss.org/browse/ISPN-8521
             Project: Infinispan
          Issue Type: Task
          Components: Core
    Affects Versions: 9.2.0.Alpha2
            Reporter: Dan Berindei
            Assignee: William Burns


The JVM can store object pointers as 4-byte ints even on machines with > 32GB of RAM, as long as the heap itself is < 32GB, by using the fact that Java objects are always aligned to 8 bytes:

{{address = stored_pointer << 3 + base}}

Off-heap relies on the platform malloc (via {{Unsafe.allocateMemory}}), so it cannot guarantee that all off-heap allocations are in a 32GB range (except in a 32-bit JVM, of course). But that should work on a machine with less than 32GB of RAM, and it may also work if the JVM runs in a Docker container limited to < 32GB.

If we allocated one big block at startup and did our own memory management, we could both guarantee that all allocations are in a 32GB range, and increase the alignment of our entries in order to use a bigger shift (e.g. align to 32 bytes and shift by 5, for a maximum of 128GB).

Doing the alignment on top of {{Unsafe.allocateMemory()}} would probably waste more memory than the small pointers would save, but it's more feasible with a native library: [posix_memalign|http://man7.org/linux/man-pages/man3/posix_memalign.3.html].

Another option would be to use open addressing instead of separate chaining with linked lists for our hash table. The table in {{MemoryAddressHash}} would have to keep the full addresses of the entries, but the LRU next/previous pointers could be replaced by table indexes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)