RFR(L): 8029075 - String deduplication in G1

[Per Liden]

Just an additional comment below.

On 2014-03-11 14:08, 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?
>
>> 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.

Just to be super clear here. There are indeed many details to hash out 
before anything like this would be implemented. I'm just brainstorming 
here. This isn't something I (or anyone else in the GC team) is 
currently working on, but if we believe some of these ideas can improve 
reference handling it might be worth considering as a future project.

cheers,
/Per

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