RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to jweak values
Kim Barrett
kim.barrett at oracle.com
Thu Nov 2 03:47:00 UTC 2017
> On Nov 1, 2017, at 5:10 PM, Doug Simon <doug.simon at oracle.com> wrote:
>
>
>
>> On 1 Nov 2017, at 18:57, Kim Barrett <kim.barrett at oracle.com> wrote:
>>
>>> On Nov 1, 2017, at 5:44 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
>>>
>>> Hi Kim,
>>>
>>> On 2017-11-01 06:03, Kim Barrett wrote:
>>>>> On Oct 30, 2017, at 7:14 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>> JNIHandles::resolve with G1 should conditionally enqueue the oops if the SATB queue is activated, which it will not be after marking terminated. At this point, marking should have terminated already, and hence the resolve will not change the liveness of the oop. So I don't quite see how the resolve will change the oop to live here. Am I missing something?
>>
>> Does this nmethod pass get run during young collections? If not, then maybe you are right that it doesn’t matter.
>>
>> But I still think that a cleanup pass that is based on using weak references like this should just be properly ordered
>> wrto weak reference processing, as it presumably already was. In which case the resolve and can_unload is
>> effectively useless; either the jweak has been cleared and we won’t reach this clause, or the jweak has not been
>> cleared because the referent is still live, in which case can_unload will always return false and there was no point
>> in calling it.
>
> I agree. As stated previously, my (defensive) code is based on assuming that nmethod unloading might happen before reference processing. If it never/rarely happens, then your suggested change is the right one. I did some extra testing and never saw it happen. Based on that, I'd like to adopt your solution. In the worst case, nmethod unloading will be delayed one full GC cycle if nmethod unloading precedes reference processing.
>
> I've created another rev based on this:
>
> http://cr.openjdk.java.net/~dnsimon/8188102_3
>
> -Doug
This looks good.
------------------------------------------------------------------------------
src/hotspot/share/runtime/jniHandles.cpp
I'd like is_global_weak_cleared moved up a few lines, immediately
following the specializations of resolve_jweak, which I think it is
closely related to.
I don't need another webrev for this.
------------------------------------------------------------------------------
src/hotspot/share/code/nmethod.cpp
2934 char* nmethod::jvmci_installed_code_name(char* buf, size_t buflen) {
2935 if (!this->is_compiled_by_jvmci()) {
2936 return NULL;
2937 }
2938 oop installed_code = JNIHandles::resolve(_jvmci_installed_code);
Are there any circumstances where it would be unfortunate to have
getting the name keep alive the object? I was thinking logging. Or
perhaps it's a feature that getting the name might artificially extend
the lifetime? Looking at the callers, it doesn't seem like a problem
right now.
This is one of those places where a "peek" access (coming soon from
the GC interface) might be appropriate.
------------------------------------------------------------------------------
X-sender: <hotspot-gc-dev-bounces at openjdk.java.net>
X-Receiver: <rene.schuenemann at sap.com>
X-CreatedBy: MSExchange15
X-HeloDomain: mx.expurgate.net
X-ExtendedProps: BQBjAAoAOtZ9Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAN8nAAB1AAAABQBkAA8ABAAAAEVkZ2UX-Source: SMTP:External Receive Connector
X-SourceIPAddress: 194.145.224.110
X-EndOfInjectedXHeaders: 8915
Received: from mx.expurgate.net (194.145.224.110) by smtpgw03.sap-ag.de
(155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov
2017 04:48:05 +0100
Received: from mx.expurgate.net (helo=localhost)
by mx.expurgate.net with esmtp
id 1eA6U9-0007UQ-7z
for rene.schuenemann at sap.com; Thu, 02 Nov 2017 04:48:05 +0100
Received: from [141.146.126.229] (helo¬sinet41.oracle.com)
by mxtls.expurgate.net with ESMTPS (eXpurgate 4.3.1)
(envelope-from <hotspot-gc-dev-bounces at openjdk.java.net>)
id 59fa956e-036c-c0a8039809dd-8d927ee532db-3
for <multiple-recipients>; Thu, 02 Nov 2017 04:48:04 +0100
Received: from aojmv0009 (unknown [137.254.59.6]) by acsinet41.oracle.com with smtp
id 645c_08a3_eef3c025_1258_41a3_ab9b_b459ba183827;
Thu, 02 Nov 2017 03:47:40 +0000
Received: from aojmv0009.oracle.com (localhost [127.0.0.1])
by aojmv0009 (Postfix) with ESMTP id 1EBDE229BAC;
Thu, 2 Nov 2017 03:50:23 +0000 (UTC)
X-Original-To: hotspot-gc-dev at openjdk.java.net
Delivered-To: hotspot-gc-dev at openjdk.java.net
Received: from acsinet40.oracle.com (acsinet40.oracle.com [141.146.126.228])
by aojmv0009 (Postfix) with ESMTP id 4ECB7229B7C;
Thu, 2 Nov 2017 03:50:19 +0000 (UTC)
Received: from aserp1040.oracle.com (unknown [141.146.126.69]) by
acsinet40.oracle.com with smtp
(TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-GCM-SHA384)
id 4a75_ed4c_f697796b_06c7_46c7_9bfb_97aa86676c35;
Thu, 02 Nov 2017 03:47:07 +0000
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234])
by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id
vA23l7mg021860
(version=TLSv1.2 cipherìDHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK);
Thu, 2 Nov 2017 03:47:07 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA23l7jf021541
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK);
Thu, 2 Nov 2017 03:47:07 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA23l6ae016734;
Thu, 2 Nov 2017 03:47:06 GMT
Received: from dhcp-10-152-15-141.usdhcp.oraclecorp.com (/10.152.15.141)
by default (Oracle Beehive Gateway v4.0)
with ESMTP ; Wed, 01 Nov 2017 20:47:06 -0700
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to
jweak values
From: Kim Barrett <kim.barrett at oracle.com>
In-Reply-To: <111F6116-A1A4-4308-BAEC-D471F9E974B9 at oracle.com>
Date: Wed, 1 Nov 2017 23:47:00 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <CD3B456E-8FB6-4295-ADAD-45BEDBD3E81F at oracle.com>
References: <94B50A35-9898-47BA-8F20-A829FD7547AC at oracle.com>
<E0D909B8-A115-4F83-9D0B-12E3FCF7EBEB at oracle.com>
<BDD0189D-ECBF-42A8-BDDE-2014753B53C9 at oracle.com>
<BABEA69B-939D-4863-9A5B-271F32F330EB at oracle.com>
<59F99795.6090404 at oracle.com>
<33980406-F96C-434E-AAB7-949B39D46026 at oracle.com>
<111F6116-A1A4-4308-BAEC-D471F9E974B9 at oracle.com>
To: Doug Simon <doug.simon at oracle.com>
X-Mailer: Apple Mail (2.3273)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
CC: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>, "hotspot-gc-dev
openjdk.java.net" <hotspot-gc-dev at openjdk.java.net>, Tom Rodriguez
<tom.rodriguez at oracle.com>
X-BeenThere: hotspot-gc-dev at openjdk.java.net
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Technical discussion about the development of the HotSpot garbage
collectors <hotspot-gc-dev.openjdk.java.net>
List-Unsubscribe: <http://mail.openjdk.java.net/mailman/options/hotspot-gc-dev>,
<mailto:hotspot-gc-dev-request at openjdk.java.net?subject=unsubscribe>
List-Archive: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/>
List-Post: <mailto:hotspot-gc-dev at openjdk.java.net>
List-Help: <mailto:hotspot-gc-dev-request at openjdk.java.net?subject=help>
List-Subscribe: <http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-dev>,
<mailto:hotspot-gc-dev-request at openjdk.java.net?subject=subscribe>
Errors-To: hotspot-gc-dev-bounces at openjdk.java.net
Sender: hotspot-gc-dev <hotspot-gc-dev-bounces at openjdk.java.net>
X-purgate-ID: tlsNG-9b2b54/1509594485-0000036C-FB75D426/9/51289
X-purgate-type: clean
X-purgate-size: 3238
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtZ2MtZGV2LWJvdW5jZXNAb3Blbmpkay5qYXZhLm5ldAByZW5lLnNjaHVlbmVtYW5uQHNhcC5jb20AYjM1ZDE3M2UyNjhjNDNjMDRmMjBhNzhiMDY1ZGU1ZTE1ZmM5M2I2ZQ=
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate: clean
X-SAP-SPAM-Status: clean
Return-Path: hotspot-gc-dev-bounces at openjdk.java.net
X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 03:48:05.5655
(UTC)
X-MS-Exchange-Organization-OriginalClientIPAddress: 194.145.224.110
X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98
X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp
X-MS-Exchange-Organization-Network-Message-Id: 179037f5-0281-4084-7800-08d521a48663
X-MS-Exchange-Organization-OriginalSize: 8593
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress:
LSRVÞWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE959.013|UTH=0.001|RST959.013|CATCM-McAfeeTxRoutingAgent=0.002|CATCM=0.003|CAT=0.004;2017-11-02T08:14:04.578Z
> On Nov 1, 2017, at 5:10 PM, Doug Simon <doug.simon at oracle.com> wrote:
>
>
>
>> On 1 Nov 2017, at 18:57, Kim Barrett <kim.barrett at oracle.com> wrote:
>>
>>> On Nov 1, 2017, at 5:44 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
>>>
>>> Hi Kim,
>>>
>>> On 2017-11-01 06:03, Kim Barrett wrote:
>>>>> On Oct 30, 2017, at 7:14 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>> JNIHandles::resolve with G1 should conditionally enqueue the oops if the SATB queue is activated, which it will not be after marking terminated. At this point, marking should have terminated already, and hence the resolve will not change the liveness of the oop. So I don't quite see how the resolve will change the oop to live here. Am I missing something?
>>
>> Does this nmethod pass get run during young collections? If not, then maybe you are right that it doesn’t matter.
>>
>> But I still think that a cleanup pass that is based on using weak references like this should just be properly ordered
>> wrto weak reference processing, as it presumably already was. In which case the resolve and can_unload is
>> effectively useless; either the jweak has been cleared and we won’t reach this clause, or the jweak has not been
>> cleared because the referent is still live, in which case can_unload will always return false and there was no point
>> in calling it.
>
> I agree. As stated previously, my (defensive) code is based on assuming that nmethod unloading might happen before reference processing. If it never/rarely happens, then your suggested change is the right one. I did some extra testing and never saw it happen. Based on that, I'd like to adopt your solution. In the worst case, nmethod unloading will be delayed one full GC cycle if nmethod unloading precedes reference processing.
>
> I've created another rev based on this:
>
> http://cr.openjdk.java.net/~dnsimon/8188102_3
>
> -Doug
This looks good.
------------------------------------------------------------------------------
src/hotspot/share/runtime/jniHandles.cpp
I'd like is_global_weak_cleared moved up a few lines, immediately
following the specializations of resolve_jweak, which I think it is
closely related to.
I don't need another webrev for this.
------------------------------------------------------------------------------
src/hotspot/share/code/nmethod.cpp
2934 char* nmethod::jvmci_installed_code_name(char* buf, size_t buflen) {
2935 if (!this->is_compiled_by_jvmci()) {
2936 return NULL;
2937 }
2938 oop installed_code = JNIHandles::resolve(_jvmci_installed_code);
Are there any circumstances where it would be unfortunate to have
getting the name keep alive the object? I was thinking logging. Or
perhaps it's a feature that getting the name might artificially extend
the lifetime? Looking at the callers, it doesn't seem like a problem
right now.
This is one of those places where a "peek" access (coming soon from
the GC interface) might be appropriate.
------------------------------------------------------------------------------
X-sender: <hotspot-gc-dev-bounces at openjdk.java.net>
X-Receiver: <gunter.haug at sap.com>
X-CreatedBy: MSExchange15
X-HeloDomain: mx.expurgate.net
X-ExtendedProps: BQBjAAoAONZ9Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAOUnAAB1AAAABQBkAA8ABAAAAEVkZ2UX-Source: SMTP:External Receive Connector
X-SourceIPAddress: 194.145.224.110
X-EndOfInjectedXHeaders: 8902
Received: from mx.expurgate.net (194.145.224.110) by smtpgw03.sap-ag.de
(155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov
2017 04:48:07 +0100
Received: from mx.expurgate.net (helo=localhost)
by mx.expurgate.net with esmtp
id 1eA6U9-0007UQ-6v
for gunter.haug at sap.com; Thu, 02 Nov 2017 04:48:05 +0100
Received: from [141.146.126.229] (helo¬sinet41.oracle.com)
by mxtls.expurgate.net with ESMTPS (eXpurgate 4.3.1)
(envelope-from <hotspot-gc-dev-bounces at openjdk.java.net>)
id 59fa956e-036c-c0a8039809dd-8d927ee532db-3
for <multiple-recipients>; Thu, 02 Nov 2017 04:48:04 +0100
Received: from aojmv0009 (unknown [137.254.59.6]) by acsinet41.oracle.com with smtp
id 645c_08a3_eef3c025_1258_41a3_ab9b_b459ba183827;
Thu, 02 Nov 2017 03:47:40 +0000
Received: from aojmv0009.oracle.com (localhost [127.0.0.1])
by aojmv0009 (Postfix) with ESMTP id 1EBDE229BAC;
Thu, 2 Nov 2017 03:50:23 +0000 (UTC)
X-Original-To: hotspot-gc-dev at openjdk.java.net
Delivered-To: hotspot-gc-dev at openjdk.java.net
Received: from acsinet40.oracle.com (acsinet40.oracle.com [141.146.126.228])
by aojmv0009 (Postfix) with ESMTP id 4ECB7229B7C;
Thu, 2 Nov 2017 03:50:19 +0000 (UTC)
Received: from aserp1040.oracle.com (unknown [141.146.126.69]) by
acsinet40.oracle.com with smtp
(TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-GCM-SHA384)
id 4a75_ed4c_f697796b_06c7_46c7_9bfb_97aa86676c35;
Thu, 02 Nov 2017 03:47:07 +0000
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234])
by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id
vA23l7mg021860
(version=TLSv1.2 cipherìDHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK);
Thu, 2 Nov 2017 03:47:07 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA23l7jf021541
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK);
Thu, 2 Nov 2017 03:47:07 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22])
by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA23l6ae016734;
Thu, 2 Nov 2017 03:47:06 GMT
Received: from dhcp-10-152-15-141.usdhcp.oraclecorp.com (/10.152.15.141)
by default (Oracle Beehive Gateway v4.0)
with ESMTP ; Wed, 01 Nov 2017 20:47:06 -0700
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: RFR: 8188102: [JVMCI] Convert special JVMCI oops in nmethod to
jweak values
From: Kim Barrett <kim.barrett at oracle.com>
In-Reply-To: <111F6116-A1A4-4308-BAEC-D471F9E974B9 at oracle.com>
Date: Wed, 1 Nov 2017 23:47:00 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <CD3B456E-8FB6-4295-ADAD-45BEDBD3E81F at oracle.com>
References: <94B50A35-9898-47BA-8F20-A829FD7547AC at oracle.com>
<E0D909B8-A115-4F83-9D0B-12E3FCF7EBEB at oracle.com>
<BDD0189D-ECBF-42A8-BDDE-2014753B53C9 at oracle.com>
<BABEA69B-939D-4863-9A5B-271F32F330EB at oracle.com>
<59F99795.6090404 at oracle.com>
<33980406-F96C-434E-AAB7-949B39D46026 at oracle.com>
<111F6116-A1A4-4308-BAEC-D471F9E974B9 at oracle.com>
To: Doug Simon <doug.simon at oracle.com>
X-Mailer: Apple Mail (2.3273)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
CC: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>, "hotspot-gc-dev
openjdk.java.net" <hotspot-gc-dev at openjdk.java.net>, Tom Rodriguez
<tom.rodriguez at oracle.com>
X-BeenThere: hotspot-gc-dev at openjdk.java.net
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Technical discussion about the development of the HotSpot garbage
collectors <hotspot-gc-dev.openjdk.java.net>
List-Unsubscribe: <http://mail.openjdk.java.net/mailman/options/hotspot-gc-dev>,
<mailto:hotspot-gc-dev-request at openjdk.java.net?subject=unsubscribe>
List-Archive: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/>
List-Post: <mailto:hotspot-gc-dev at openjdk.java.net>
List-Help: <mailto:hotspot-gc-dev-request at openjdk.java.net?subject=help>
List-Subscribe: <http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-dev>,
<mailto:hotspot-gc-dev-request at openjdk.java.net?subject=subscribe>
Errors-To: hotspot-gc-dev-bounces at openjdk.java.net
Sender: hotspot-gc-dev <hotspot-gc-dev-bounces at openjdk.java.net>
X-purgate-ID: tlsNG-9b2b54/1509594485-0000036C-FB75D426/9/51289
X-purgate-type: clean
X-purgate-size: 3238
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtZ2MtZGV2LWJvdW5jZXNAb3Blbmpkay5qYXZhLm5ldABndW50ZXIuaGF1Z0BzYXAuY29tAGZlZTE1ZDY4ODdjMjM2Zjc5NDNiNDAwNzc4ZTdkODM2YzhjZGIzZGMX-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate: clean
X-SAP-SPAM-Status: clean
Return-Path: hotspot-gc-dev-bounces at openjdk.java.net
X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 03:48:07.7218
(UTC)
X-MS-Exchange-Organization-OriginalClientIPAddress: 194.145.224.110
X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98
X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp
X-MS-Exchange-Organization-Network-Message-Id: fd121385-9359-4a1d-7c94-08d521a487ac
X-MS-Exchange-Organization-OriginalSize: 8580
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress:
LSRVÞWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE956.873|UTH=0.001|RST956.857|CATCM-McAfeeTxRoutingAgent=0.002|CATCM=0.002|CAT=0.003;2017-11-02T08:14:04.594Z
> On Nov 1, 2017, at 5:10 PM, Doug Simon <doug.simon at oracle.com> wrote:
>
>
>
>> On 1 Nov 2017, at 18:57, Kim Barrett <kim.barrett at oracle.com> wrote:
>>
>>> On Nov 1, 2017, at 5:44 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
>>>
>>> Hi Kim,
>>>
>>> On 2017-11-01 06:03, Kim Barrett wrote:
>>>>> On Oct 30, 2017, at 7:14 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>> JNIHandles::resolve with G1 should conditionally enqueue the oops if the SATB queue is activated, which it will not be after marking terminated. At this point, marking should have terminated already, and hence the resolve will not change the liveness of the oop. So I don't quite see how the resolve will change the oop to live here. Am I missing something?
>>
>> Does this nmethod pass get run during young collections? If not, then maybe you are right that it doesn’t matter.
>>
>> But I still think that a cleanup pass that is based on using weak references like this should just be properly ordered
>> wrto weak reference processing, as it presumably already was. In which case the resolve and can_unload is
>> effectively useless; either the jweak has been cleared and we won’t reach this clause, or the jweak has not been
>> cleared because the referent is still live, in which case can_unload will always return false and there was no point
>> in calling it.
>
> I agree. As stated previously, my (defensive) code is based on assuming that nmethod unloading might happen before reference processing. If it never/rarely happens, then your suggested change is the right one. I did some extra testing and never saw it happen. Based on that, I'd like to adopt your solution. In the worst case, nmethod unloading will be delayed one full GC cycle if nmethod unloading precedes reference processing.
>
> I've created another rev based on this:
>
> http://cr.openjdk.java.net/~dnsimon/8188102_3
>
> -Doug
This looks good.
------------------------------------------------------------------------------
src/hotspot/share/runtime/jniHandles.cpp
I'd like is_global_weak_cleared moved up a few lines, immediately
following the specializations of resolve_jweak, which I think it is
closely related to.
I don't need another webrev for this.
------------------------------------------------------------------------------
src/hotspot/share/code/nmethod.cpp
2934 char* nmethod::jvmci_installed_code_name(char* buf, size_t buflen) {
2935 if (!this->is_compiled_by_jvmci()) {
2936 return NULL;
2937 }
2938 oop installed_code = JNIHandles::resolve(_jvmci_installed_code);
Are there any circumstances where it would be unfortunate to have
getting the name keep alive the object? I was thinking logging. Or
perhaps it's a feature that getting the name might artificially extend
the lifetime? Looking at the callers, it doesn't seem like a problem
right now.
This is one of those places where a "peek" access (coming soon from
the GC interface) might be appropriate.
------------------------------------------------------------------------------
More information about the hotspot-gc-dev
mailing list