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

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

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

Erik Österlund-2
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

Jiangli Zhou
Hi Erik,

Thanks a lot for the refactoring. I’m really glad that the G1 specific code for explicit enqueuing is no longer needed in shared code when an archived object becomes ‘in use’.

Thanks,
Jiangli

> On Jan 10, 2018, at 6:29 AM, Erik Österlund <[hidden email]> 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 Jiangli,

You are welcome. :)

/Erik

On 2018-01-10 20:54, Jiangli Zhou wrote:

> Hi Erik,
>
> Thanks a lot for the refactoring. I’m really glad that the G1 specific code for explicit enqueuing is no longer needed in shared code when an archived object becomes ‘in use’.
>
> Thanks,
> Jiangli
>
>> On Jan 10, 2018, at 6:29 AM, Erik Österlund <[hidden email]> 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