RFR(L): 8029075 - String deduplication in G1
per.liden at oracle.com
Tue Mar 11 11:24:22 UTC 2014
On 2014-03-11 04:44, David Holmes wrote:
> On 11/03/2014 4:18 AM, Christian Thalinger wrote:
>> On Mar 10, 2014, at 5:36 AM, Per Liden <per.liden at oracle.com> wrote:
>>> The other part of the story, orthogonal to the memory overhead, is
>>> making reference processing more efficient once the referent becomes
>>> unreachable. I've seen many cases where heavy use of weak references
>>> (registered or not) overloads the reference handler thread.
>> Interesting. Is that because it’s just one thread? How about using
>> something like ThreadPoolExecutor for the reference handler thread(s)?
> The synchronization that would be needed across multiple
> reference-handler threads might negate any benefit from having more
> than one. And a full blown ThreadPoolExecutor may be overkill here.
Gut feeling also tells me that the synchronization would kill it, but
might be worth a try.
>>> To improve that situation, I'd like to see the reference handler
>>> thread removed completely, and instead let the GC enqueue reference
>>> directly onto the reference queues.
> That would require that the GC threads be able to execute Java code.
> It would also mean that a GC thread would experience synchronization
> (and possible contention) with Java threads.
I was more like thinking of modifying the underlying queue in
ReferenceQueue so that the GC could enqueue entries from a native
context (somewhat similar to how the pending list works today).
Admittedly, I haven't thought about all the details here, but I'm
thinking that should be doable with a CAS in the fast path for both
enqueue and dequeue, and maybe allow a down call from
ReferenceQueue.remove() in the slow path in case the queue is empty and
the caller needs to block (say, on a ParkEvent maybe). Does that sound
>>>> — John
>>>> P.S. Connection with value types: Eventually, we could add value
>>>> like java.lang.ref.WeakReferenceValue which would provide a standard
>>>> form for this. Or we could standardize the annotation, perhaps.
>>>> P.P.S. For a little more on value types, see
More information about the hotspot-dev