RFR(L): 8029075 - String deduplication in G1

[David Holmes]

On 11/03/2014 11:08 PM, Per Liden wrote:
> 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?

Yes the Cleaner.

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

Again this is not so simple in that it involves synchronization with the 
Java threads - to do a notifyAll you need the monitor and the monitor 
may be locked by a thread now paused at a safepoint because of the 
current GC action.

Cheers,
David

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