RFR(L): 8029075 - String deduplication in G1

[David Holmes]

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, 
and enqueuing requires waking up blocked Java threads. Simple atomic ops 
to add elements to the queue would not in themselves be sufficient. The 
details need to be fleshed out here.

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