Records cannot be properly used in caches

[JacobKeegan]

If a cache is sized using MemoryUnit, and the cache key or value contains a record (which were added in Java 17), any attempt to put a value in the cache will fail. The core cause of this failure is this line in sun.misc.Unsafe:

if (declaringClass.isRecord()) {
     throw new UnsupportedOperationException("can't get field offset on a record class: " + f);
}

A simple project which shows the issue in practice is linked here.
This seems like a serious issue, because Ehcache gives no clear indication of why this failure happens, and records are natural to use as keys.

[chrisdennis]

There are two ways round this right now:

1. Not use byte based sizing.
2. Configure an explicit size-of-engine to avoid the Unsafe size-of engine strategy. That's going to mean resorting to the reflection based sizing approach. Essentially duplicating the existing size-of-engine logic but with something like the following applied:

Index: ehcache-impl/src/main/java/org/ehcache/impl/internal/sizeof/DefaultSizeOfEngine.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/ehcache-impl/src/main/java/org/ehcache/impl/internal/sizeof/DefaultSizeOfEngine.java b/ehcache-impl/src/main/java/org/ehcache/impl/internal/sizeof/DefaultSizeOfEngine.java
--- a/ehcache-impl/src/main/java/org/ehcache/impl/internal/sizeof/DefaultSizeOfEngine.java	(revision 8092a5b98f8fa27335377bf1884ac1d708028bd0)
+++ b/ehcache-impl/src/main/java/org/ehcache/impl/internal/sizeof/DefaultSizeOfEngine.java	(date 1649711593049)
@@ -25,6 +25,8 @@
 import org.ehcache.sizeof.SizeOfFilterSource;
 import org.ehcache.core.spi.store.Store;
 import org.ehcache.core.spi.store.heap.SizeOfEngine;
+import org.ehcache.sizeof.filters.CombinationSizeOfFilter;
+import org.ehcache.sizeof.impl.ReflectionSizeOf;
 
 /**
  * @author Abhilash
@@ -41,7 +43,7 @@
   public DefaultSizeOfEngine(long maxObjectGraphSize, long maxObjectSize) {
     this.maxObjectGraphSize = maxObjectGraphSize;
     this.maxObjectSize = maxObjectSize;
-    this.sizeOf = SizeOf.newInstance(new SizeOfFilterSource(true).getFilters());
+    this.sizeOf = new ReflectionSizeOf(new CombinationSizeOfFilter(new SizeOfFilterSource(true).getFilters()));
     this.onHeapKeyOffset = sizeOf.deepSizeOf(new CopiedOnHeapKey<>(new Object(), new IdentityCopier<>()));
     this.chmTreeBinOffset = sizeOf.deepSizeOf(ConcurrentHashMap.FAKE_TREE_BIN);
   }

Long term we're going to have to take a long hard look at the whole feature. The JDK is not moving in a direction such that any of this is getting easier. There's some obvious cleanup we can do that will make things better... but I'm wary of sunk-cost fallacies.

[linghengqian]

In the long run, should the byte-based cache be spun off as a separate dependency from Ehcache, the base Ehcache only provides a number-based cache and a range of applications?

[chrisdennis]

In the long term (exactly how long is not clear...) we'll probably be dropping internal support for byte sized caches. I won't drop the ability to configure them... but there will be no built-in store provider that would handle those configurations. If/when this happens it would be associated with a bump of the Java support to 1.11 minimum, and a bunch of overhaul of the underlying code to take advantage of that.

[chrisdennis]

This will require the productizing and merging of ehcache/sizeof#64.