ehcache / sizeof Goto Github PK

Something weird in upgrading from 0.4 to all newer versions "org.slf4j.spi.LoggingEventAware not found"

    Logger log = CONTEXT.getLogger(LoggingConfiguration.class);
    log.info("Console logger configured.  env: " + env + " color: " + useColor + " " + this.hashCode());

Second line is the one with the issue, no idea why.

Both code and maven groupId

Hi
seem gmaven is dead (latest release published 20 Sep 2013 )
can you replace with org.codehaus.gmavenplus:gmavenplus-plugin:1.5 ( published 9 Mar 2015 )?
i added this code to the pom file, and seem work

<executions>
  <execution>
    <id>create-agent-jar</id>
    <phase>process-classes</phase>
    <goals>
      <goal>execute</goal>
    </goals>
  </execution>
</executions>
<configuration>
  <scripts>
    <script><![CDATA[
      def jarFile = new File(project.build.directory, "/classes/org/ehcache/sizeof/impl/sizeof-agent.jar");
      def agentClass = "/org/ehcache/sizeof/impl/SizeOfAgent.class"
      def agentDir = project.build.directory + "/agent-jar"
      def manifestDir = project.basedir.getAbsolutePath() + "/src/hidden/resources";
      ant.move(file: new File(project.build.outputDirectory, agentClass),
      tofile: new File(agentDir, agentClass))

      ant.jar(destfile: jarFile, basedir: new File(agentDir).getAbsolutePath(), manifest: new File(manifestDir, "/META-INF/MANIFEST.MF"))

      ant.delete(dir: new File(agentDir))
    ]]></script>
  </scripts>
</configuration>
<dependencies>
  <dependency>
    <groupId>org.codehaus.groovy</groupId>
    <artifactId>groovy-all</artifactId>
    <version>2.4.4</version>
    <scope>runtime</scope>
  </dependency>
</dependencies>

Thanks in advance for every suggestions
Regards

Good day,

I've tried to use this library (version 0.4.0) on JDK17 and it seems work fine with one exception: it can't measure the standard collections like HashSet. deepSizeOf returns 32 bytes for example.

Is it know limitation or a bug?

It reports only one warning BTW:

WARNING: sun.reflect.Reflection.getCallerClass is not supported. This will impact performance.

... at least to the public API (i.e. net.sf.ehcache.suzeofengine.filterconfigurator & net.sf.ehcache.sizeofengine.Filter)

Can you please publish to Maven Central? Despite there having been a 0.1.0 release, the publish to Central didn't seem to happen - I don't see "sizeofengine" under http://repo1.maven.org/maven2/net/sf/ehcache/ as I would expect. Thanks!

So this is actually usable by someone

So the lib gets usable w/o ehcache on the class path.
Most of the work happened actually already, without a real issue associated I think, but there is one reference left in the AgentLoader code

After playing a bit with Java 9, here is what I've found:

• Java 9 can't load the agent. So UnsafeSizeOf is used
• Then it works well excecpt: We get Illegal access warnings from ObjectGraphWalker

Also, Java 9 is using less memory (good!) so we need to adapt our tests accordingly.

Hello team,

I am using this dependency:

I am also using java 21.

I have a very straightforward object I would like to get the size of.

Please note, the object in question is a java record, which is something new from new java version.

public record MyPojo(@JsonProperty(value = "@timestamp") String timestamp

reproducible 100%, i am getting this error:

java.lang.UnsupportedOperationException: can't get field offset on a record class: private final java.lang.String com.MyPojo.timestamp
Caused by: java.lang.UnsupportedOperationException: can't get field offset on a record class: private final java.lang.String com.MyPojo.timestamp
	at jdk.unsupported/sun.misc.Unsafe.objectFieldOffset(Unsafe.java:655)
	at org.ehcache.sizeof.impl.UnsafeSizeOf.sizeOf(UnsafeSizeOf.java:120)
	at org.ehcache.sizeof.SizeOf$CachingSizeOfVisitor.visit(SizeOf.java:127)
	at org.ehcache.sizeof.ObjectGraphWalker.walk(ObjectGraphWalker.java:168)
	at org.ehcache.sizeof.SizeOf.deepSizeOf(SizeOf.java:74)

Could you please help support record?

Thank you

... as this screws with some of the "ugly" tests we have in there...

(on version 0.2.0, using ehcache version 3.0.2)

I was getting the following WARN-level logs when attempting to cache a certain object:

Max Object Graph Size reached for the object

thrown from here.

In order to determine why I was getting this, I set the traversalDebugMessage to true (using the log levels and the system property) and I can see in a debugger that it's being appended to as it's being walked.

The issue is, if anything in the walk method throws a RuntimeException, the code that ultimately provides the message to the logger is never called.

This code should be wrapped in a finally clause to log the traversalDebugMessage. Without those logs it's difficult to debug errors like the one given above.

Thank you!

This should contain all sizeOf code independently of Ehcache's

Soft references cause all sorts of problems with garbage collection and cannot reliably be used for caching, which is what the ObjectGraphWalker uses them for.

Another form of Field caching should be used.

Currently these are hard ref'ed

Following the work on adding OpenJDK support, the SizeOfTestValues static init block was not updated with entries for OpenJDK.
This will cause the SizeOfTest.testSizeOf to fail - if it runs - which is why this was not detected immediately.

Fix will be to add the corresponding mappings for OpenJDK VMs in SizeOfTestValues.

Executing the basic load of size of in AdopyOpenJDK 10.0.1:

    final SizeOf sizeof = SizeOf.newInstance();
    return sizeof.deepSizeOf( object );

Returns this exception:

InaccessibleObjectException:
java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.lang.Object jdk.internal.loader.AbstractClassLoaderValue$Sub.key accessible: module java.base does not "opens jdk.internal.loader" to unnamed module

When ObjectGraphWalker exceeds the max depth, it throws an IllegalArgumentException. However EhcacheSizeOfEngine is expecting to catch a MaxDepthExceededException. The IllegalArgumentException bubbles up past that catch and a stack trace is logged.

This is odd, given that the sizeof engine in EhCache 2.8 throws the correct MaxDepthExceededException.

While the existing README indicates which repository to add to get to SNAPSHOT version, it does not indicate the maven coordinates for the project.
They should be added for easier inclusion in maven builds.

We don't want that in the core API

ObjectGraphWalkerTest for instance throws java.lang.AssertionError: Unexpected Java Version : 1.8.0_73
AgentLoaderRaceTest has assumeThat(System.getProperty("java.version"), anyOf(startsWith("1.6"), startsWith("1.7"))); in a @BeforeClass method
SizeOfTestValues has some switch (jvmVersion) with no case for version 8 and above.

The tests should be adapted to run on the more modern JDKs.

We need to have a better README.adoc to get people started.
Also need to (re?)add attributions & links to Heinz's newsletters on the sizeof stuff!

ReflectionSizeOf has an alignment bug, which can be seen while running JDK 1.6.0 > v60 for test SizeOfTest.
It looks like the per-class alignment needs to be done not using the pointer size but using the primitive type reference size.

pom.xml needs to be updated to reflect the current location of the project.

The recently added test, related to issue #21, creates classes that are compatible only with Java 1.7
This is a unnecessary limitation and we should still support Java 1.6

Test environment is linux,amd64

With compressed references.

• Empty array reported as using 16 bytes by Agent but 8 bytes by Unsafe.
• new Object[1] is reported as using 16 bytes by Agent and Unsafe.

With compressed references disabled,

• new Object() size is reported as 16 bytes by Agent and 24 bytes by Unsafe

Header sizes in JvmInformation appear to be incorrect

• 16 bytes for 32 bit /compressed refs, 24 bytes for uncompressed refs

( ehcache version org.ehcache:ehcache:3.9.9 java 11)
WARN 8418 --- [nio-8080-exec-2] org.ehcache.sizeof.ObjectGraphWalker : The JVM is preventing Ehcache from accessing the subgraph beneath 'private final byte[] java.lang.String.value' - cache sizes may be underestimated as a result

CacheConfiguration<String,CachedValueWrapper> cacheConfiguration= CacheConfigurationBuilder
.newCacheConfigurationBuilder(String.class, CachedValueWrapper.class,
newResourcePoolsBuilder().heap(100, MemoryUnit.MB))
.withExpiry(ExpiryPolicyBuilder.timeToLiveExpiration(Duration.parse("PT30S")))
.build();

I am new to caching and was wondering if this is due to insufficient space in the heap memory?