[
https://issues.apache.org/jira/browse/OPENJPA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491104
]
Patrick Linskey commented on OPENJPA-219:
-----------------------------------------
I agree about the mem leak problem in the patch that I created; hence my
comments in the original post about using weak references. There are a number
of ways that you could solve this caching problem, such as making all / part of
Reflection non-static and setting up per-Configuration caches, or using weak
references in the cache, or even (and probably least attractively) creating
undeploy APIs.
Abe said:
> If we're going to cache, I don't see why we wouldn't cache the declared
> fields/methods rather than the nonexistent ones. It would be a simple
> matter of keeping a Class->Set cache, where the Set is the names of
> the fields/methods returned by Class.getDeclaredFields/Methods().
> Then we'd have both a positive (set.contains(x)) and negative
> (!set.contains(x)) cache.
As I mentioned in the original description, the bug here is that negative
lookups are slow because of the exception creation. I see no reason to add
extra caching if we don't know if we need it, although Bret's numbers
potentially indicate that there is a benefit to positive caching. I have no
problem with having a positive cache, but I think that we should only include
it if it's going to help, since otherwise it'll just be one more thing
contributing to memory consumption.
> 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.
