[jira] Commented: (HARMONY-5633) [classlib][luni][performance] ObjectStreamClass lookup improvement

["Alexey Varlamov (JIRA)" <ji...@apache.org>]

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

Alexey Varlamov commented on HARMONY-5633:
------------------------------------------

Aleksey, I'm afraid you misunderstand the contract and purpose of WeakHashMap: the mission is to allow GC to clean up globally mapped keys, while you try to replace it with a sort of smart cache - yet keys are never collected and class unloading is stuck.
BTW, looking closely, original ObjectStreamClass may still prevent CU due to strong links to methods of a wrapped class:
private transient Method methodWriteReplace;
private transient Method methodReadResolve;
private transient Method methodWriteObject;
private transient Method methodReadObject;
private transient Method methodReadObjectNoData;
I believe they also must be weakly referenced, will file another JIRA.

Another issue, such fast-paths are not truly thread-safe. The spec for HashMap reads:
"Note that this implementation is not synchronized. If multiple threads access this map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.) "

OTOH the "classesAndDescriptors" mapping itself seems to be mere performance optimization (just cache indeed), so does not need to be global here... Making cache TreadLocal most probably is not effective, so I see the only thread-safe way to reduce contention is a multi-bucket cache - e.g. a small array of self-synchronized WeakHashMaps + even distribution of buckets per threads. Say threads can access buckets by thread ID (take ID%aray.length as index) or via randomly selected index, etc. 
Looks scary though, needs trial :)


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