harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-5633) [classlib][luni][performance] ObjectStreamClass lookup improvement
Date Tue, 08 Apr 2008 06:57:24 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586683#action_12586683

Aleksey Shipilev commented on HARMONY-5633:

Alexey, thanks for the comment! 

1. I didn't expect the issue with CU, can you please point me to spec or doc where such contract
is defined? While I haven't one I'll try to understand in the scope of common sense. I assume
that CU initiates unloading when Class is not strongly referenced anymore. Then referencing
the class with SoftReference instead of WeakReference does not change the behavior significantly,
because SoftReference will eventually free the referent when memory is exhausted thus allowing
CU to reduce the footprint by unloading certain classes. And so the question is: whether we
have the requirement when CU should happen?

2. Yep, you're right, thanks. The get() operation is not thread-safe here. We might tolerate
this in two ways: using ConcurrentHashMap or using ThreadLocal. 

Keeping this two points in mind, how about this ways? I could check the performance of each
of them and report back.

a. Use ConcurrentHashMap<Class,SoftReference<ObjectStreamClass>>
b. Use ConcurrentHashMap<Class,WeakReference<ObjectStreamClass>>
c. Use ThreadLocal with HashMap<Class,SoftReference<ObjectStreamClass>>
d. Use ThreadLocal with WeakHashMap<Class,ObjectStreamClass>

> [classlib][luni][performance] ObjectStreamClass lookup improvement
> ------------------------------------------------------------------
>                 Key: HARMONY-5633
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5633
>             Project: Harmony
>          Issue Type: Improvement
>            Reporter: Aleksey Shipilev
>         Attachments: 0001-serial-lookupClass.patch, serial-lookupClass-RC1.patch
> For now, ObjectStreamClass (OSC) is created on-the-fly during serialization/deserialization
and stored in static cache.
> Performance problems arose when several threads doing the lookups, hitting on synchronized
cache. Moreover, the cache is built around WeakHashMap to ensure GC of OSCs. This issue is
the source of scalability problems for multi-threaded serialization benchmarks.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message