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

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)