RFR(L): 8029075 - String deduplication in G1

[Per Liden]

Inline below...

On 2014-03-11 13:04, David Holmes wrote:
> On 11/03/2014 9:24 PM, Per Liden wrote:
>> On 2014-03-11 04:44, David Holmes wrote:
>>> <trimming>
>>>
>>> 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
>> completely unreasonable?
>
> The ReferenceHandler thread does more than just enqueue the references, 

What else are you thinking of? sun.misc.Cleaner would obviously have to 
be redesigned or removed, but other than that?

> and enqueuing requires waking up blocked Java threads. Simple atomic 
> ops to add elements to the queue would not in themselves be sufficient. 

Yes, a CAS would have to be followed by a potential slow path to wakeup 
any waiter if it's the first element that goes on the queue, etc.

> The details need to be fleshed out here.

Indeed.

/Per

>
> David
>
>> /Per
>>
>>>
>>> David
>>> -----
>>>
>>>>>
>>>>> /Per
>>>>>
>>>>>>
>>>>>> — John
>>>>>>
>>>>>> P.S. Connection with value types:  Eventually, we could add value
>>>>>> types
>>>>>> 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
>>>>>> https://blogs.oracle.com/jrose/entry/value_types_and_struct_tearing
>>>>
>>