RFR(L): 8029075 - String deduplication in G1

[Per Liden]

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?

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