Gabor Papai created ISPN-9912: --------------------------------- Summary: jcache.embedded.LimitExpiryPolicy creates a NPE to control the flow, the jcache.get() could be 10% faster. Key: ISPN-9912 URL: https://issues.jboss.org/browse/ISPN-9912 Project: Infinispan Issue Type: Enhancement Components: JCache Affects Versions: 9.4.6.Final, 9.4.5.Final, 10.0.0.Alpha3 Reporter: Gabor Papai Attachments: SSCCE.zip, VisualVM-Sampling.png A jcache.get() call with expiry==eternal creates an unnecessary NPE in LimitExpiryPolicy, it's catched in Expiration.getExpiry(), and a NULL is returned. The LimitExpiryPolicy could return this NULL itself, so the NPE would not happen. In my test this NPE costs ca. 10% of a jcache.get() call (plus the garbage collection overhead). Infinispan is used through JCache interface. Details: org.infinispan.jcache.embedded.LimitExpiryFactory.LimitExpiryPolicy doesn't check the "duration" against null, so a NPE will be thrown. EternalExpiryPolicy returns NULL as getExpiryForAccess() and getExpiryForUpdate(). It leads to NPE in LimitExpiryPolicy.getExpiryForAccess() and LimitExpiryPolicy.getExpiryForUpdate(). This NPE will be in Expiration.getExpiry() catched, and it's handled as it was NULL. The LimitExpiryPolicy.getExpiryForUpdate()/getExpiryForAccess() could make the "duration==null" check itself, and could return a NULL, so would not happen the "catch(NPE) { return null; }", and so would it be faster. Attachment: SCCE.zip: small maven project with a unittest (it fails without the fix) and a "TestJCacheLimiterExpiryNpeControl" program to measure it with eg. VisualVM's sampling. VisualVM-Sampling.png: CPU Sampling with VisualVM. -- This message was sent by Atlassian Jira (v7.12.1#712002)