openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bret Weinraub (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-219) Reflection: negative caching would be beneficial in redeployment scenarios
Date Mon, 23 Apr 2007 21:50:15 GMT

    [ 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.


Mime
View raw message