[
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491077
]
Bret Weinraub commented on OPENJPA-219:
---------------------------------------
I developed a patch version that cached both "success" and "failure" cases -
here are some of the performance numbers I generated:
VM Implementation Benchmark Rate (ms)
Sun 1 - Original 333
Sun 2 - Cache v1 83
Sun 3 - Cache v2 40
JRockit 1 - Original 176
JRockit 2 - Cache v1 72
JRockit 3 - Cache v2 22
Where
Original : recent svn version
Cache V1: patch above plus a couple of minor tweaks
Cache V2: caches both success and failure calls thereby minimizing calls to
Reflection API.
Adding a boolean that says "use cache" or not would be simple.
Anyway let me add that I/we feel that permanently caching Class objects would
create memory leak problems in the case where a ClassLoader were to be thrown
away. Holding the class Object in a hash will keep the ClassLoader tree from
being garbage collected ; we see this anti-pattern frequently, it is
pathalogical, and can eventually lead to OOME for operations that recycle class
loaders. An example would be repeatedly deploying the same application to an
application server, such as done during iterative development of
WebApps/EnterpriseApps. So I/we believe to be critical to create a mechanism
whereby these Class object were not held in a static context. If this code
were associated with an object then when the object was GC-ed the Class
references would be eliminated therey by allowing the class loader to be GC-ed.
> Reflection: negative caching would be beneficial in redeployment scenarios
> --------------------------------------------------------------------------
>
> Key: OPENJPA-219
> URL: https://issues.apache.org/jira/browse/OPENJPA-219
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 0.9.0, 0.9.6, 0.9.7
> Reporter: Patrick Linskey
> Fix For: 0.9.8
>
> Attachments: OPENJPA-219.patch
>
>
> In a variety of situations, OpenJPA searches class hierarchies for fields.
> These searches invoke Class.getDeclaredField() in order to find non-public
> fields. This method throws an exception when it fails to find the specified
> field, and the exception creation is, as ever, slow.
> It would be useful to create a static (and thus per-classloader)
> Map<WeakReference<Class>,Collection<String>> of fields known not to be
> available in a given class.
> It may also be beneficial to maintain a cache of which fields *are* present
> in a given class, but this issue is being filed as a result of a demonstrated
> performance hit during deployment due to the lack of a negative cache. If we
> obtain quantitative data indicating that a positive cache would be useful, we
> might want to implement such a thing at that time.
> Trace 3 (2115 occurances): [excepti][00090] java/lang/NoSuchFieldException:
> domainName
> at
> java/lang/Class.getDeclaredField(Ljava/lang/String;I)Ljava/lang/reflect/Field;(Unknown
> Source)
> at
> org/apache/openjpa/enhance/Reflection.findField(Ljava/lang/Class;Ljava/lang/String;Z)Ljava/lang/reflect/Field;(Reflection.java:101)
> at
> org/apache/openjpa/util/ApplicationIds.toPKValues(Ljava/lang/Object;Lorg/apache/openjpa/meta/ClassMetaData;)[Ljava/lang/Object;
> (ApplicationIds.java:89)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
