Re: RFR(S): 8194741: Refactor oops in constant pool from CDS to use the Access API

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: RFR(S): 8194741: Refactor oops in constant pool from CDS to use the Access API

coleen.phillimore

This looks fine.  I don't see why you couldn't use IN_CONCURRENT_ROOT
for them, like the others though.  I like where the barrier ended up though.

thanks,
Coleen

On 1/10/18 9:29 AM, Erik Österlund wrote:

> Hi,
>
> The constant pool may install resolved_references from CDS archives.
> This installation might happen during concurrent marking. Therefore, a
> new previously known graph is mounted onto the existing Java heap
> object graph. Naturally, this makes SATB invariants confused and
> therefore requires explicit enqueuing.
>
> This patch hooks this into the Access API. While there are different
> ways that this could be annotated, I chose to introduce a new
> decorator called IN_ARCHIVE_ROOT, which similar to IN_CONCURRENT_ROOT
> denotes a kind of special root that needs to be handled differently.
> In the G1 case, it results in a SATB enqueue when it is loaded. This
> approach made me scratch my head less than various other ideas I had.
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8194741/webrev.00/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8194741
>
> /Erik

Reply | Threaded
Open this post in threaded view
|

Re: RFR(S): 8194741: Refactor oops in constant pool from CDS to use the Access API

Erik Österlund-2
Hi Coleen,

Thank you for the review. I did consider reusing IN_CONCURRENT_ROOT, but
thought I'd rather make an explicit one for the archive. The reason is
that all other concurrent roots are all visited either during a
safepoint or during concurrent scanning. But these archive roots are
never scanned by the GC, giving it slightly different semantics that I
would prefer not to mix.

Thanks,
/Erik

On 2018-01-10 15:49, [hidden email] wrote:

>
> This looks fine.  I don't see why you couldn't use IN_CONCURRENT_ROOT
> for them, like the others though.  I like where the barrier ended up
> though.
>
> thanks,
> Coleen
>
> On 1/10/18 9:29 AM, Erik Österlund wrote:
>> Hi,
>>
>> The constant pool may install resolved_references from CDS archives.
>> This installation might happen during concurrent marking. Therefore,
>> a new previously known graph is mounted onto the existing Java heap
>> object graph. Naturally, this makes SATB invariants confused and
>> therefore requires explicit enqueuing.
>>
>> This patch hooks this into the Access API. While there are different
>> ways that this could be annotated, I chose to introduce a new
>> decorator called IN_ARCHIVE_ROOT, which similar to IN_CONCURRENT_ROOT
>> denotes a kind of special root that needs to be handled differently.
>> In the G1 case, it results in a SATB enqueue when it is loaded. This
>> approach made me scratch my head less than various other ideas I had.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~eosterlund/8194741/webrev.00/
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8194741
>>
>> /Erik
>