From doug.simon at oracle.com  Thu May  1 08:52:56 2014
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 1 May 2014 10:52:56 +0200
Subject: hotspot-compiler-dev Digest, Vol 83, Issue 81
In-Reply-To: <mailman.9545.1398897700.13540.hotspot-compiler-dev@openjdk.java.net>
References: <mailman.9545.1398897700.13540.hotspot-compiler-dev@openjdk.java.net>
Message-ID: <6EDC7505-7436-4814-95A4-6A6CB09B04F1@oracle.com>


> On 4/30/14 2:35 PM, Christian Thalinger wrote:
>> 
>> On Apr 30, 2014, at 11:26 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> Morris,
>>> 
>>> How you verified that you put ResourceMark in all needed places?
>>> That is what I don't like about GrowableArray.
>> 
>> He could put a ResourceMark in front of every GrowableArray.  That would do it.
> 
> Nested ResourceMark has bad effect on external GrowableArray: if it 
> grows after inner ResourceMark that space will be released after inner 
> scope ends. You will get memory stomps because of that. You need to be 
> sure that external GrowableArray never grows inside inner ResourceMark 
> scope.

The same problem exists for expandable stringStreams[1].

-Doug

[1] http://hg.openjdk.java.net/graal/graal/file/100306ae985b/src/share/vm/graal/graalCompilerToVM.cpp#l601


From doug.simon at oracle.com  Thu May  1 08:54:06 2014
From: doug.simon at oracle.com (Doug Simon)
Date: Thu, 1 May 2014 10:54:06 +0200
Subject: RFR(S): 8040920: Uninitialised memory in
	hotspot/src/share/vm/code/dependencies.cpp
In-Reply-To: <mailman.9545.1398897700.13540.hotspot-compiler-dev@openjdk.java.net>
References: <mailman.9545.1398897700.13540.hotspot-compiler-dev@openjdk.java.net>
Message-ID: <0B68853D-03D4-4753-8C82-0A00DF9696DD@oracle.com>

(proper subject line this time)

> On 4/30/14 2:35 PM, Christian Thalinger wrote:
>> 
>> On Apr 30, 2014, at 11:26 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> Morris,
>>> 
>>> How you verified that you put ResourceMark in all needed places?
>>> That is what I don't like about GrowableArray.
>> 
>> He could put a ResourceMark in front of every GrowableArray.  That would do it.
> 
> Nested ResourceMark has bad effect on external GrowableArray: if it 
> grows after inner ResourceMark that space will be released after inner 
> scope ends. You will get memory stomps because of that. You need to be 
> sure that external GrowableArray never grows inside inner ResourceMark 
> scope.

The same problem exists for expandable stringStreams[1].

-Doug

[1] http://hg.openjdk.java.net/graal/graal/file/100306ae985b/src/share/vm/graal/graalCompilerToVM.cpp#l601


From igor.ignatyev at oracle.com  Thu May  1 13:39:05 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 01 May 2014 17:39:05 +0400
Subject: RFR(XXS) : 8042214: add @ignore tag to all excluded jtreg tests
	in test/compiler
In-Reply-To: <536157D3.5060203@oracle.com>
References: <5360F543.1030208@oracle.com> <536138B4.9030509@oracle.com>
	<53615693.5060003@oracle.com> <536157D3.5060203@oracle.com>
Message-ID: <53624E79.6050407@oracle.com>

Vladimir, thanks for reviewing.

Igor

On 05/01/2014 12:06 AM, Vladimir Kozlov wrote:
> Thank you for explanation, Igor. Changes are good.
>
> Vladimir
>
> On 4/30/14 1:01 PM, Igor Ignatyev wrote:
>> Vladimir,
>>
>>> Please, explain the usage of @ignore tag.
>>
>> @ignore tag is a regular tag from jtreg, excerpt from jtreg spec[1]:
>>> ACTION TYPES
>>> ...
>>> ignore <word>*
>>>
>>> Ignore this and all following @run tags.  A test harness may treat
>>> this test as
>>> a failure or as some other type of error.  The <word> tokens, if any,
>>> should
>>> describe why the test is being ignored.  These tokens may be
>>> displayed by the
>>> harness in some appropriate fashion.
>>
>>
>>> Will these tests run during nightly testing or not?
>> the tests marked by this tag won't be run during all testing including
>> nightly, PIT, promotion. As they do now, since
>> there's open bugs w/ 'test-exclude' label; namely JDK-8033553,
>> JDK-8032498, JDK-7117034, JDK-7154567.
>>
>> Fixing these bugs is our (SQE team) high priority task, but we need to
>> add @ignore tag due to upcoming changes in
>> exclusion mechanism.
>>
>>> How we know when the tag should be removed?
>> the tag should be removed by the fix for the bug (usually it's a
>> testbug) mentioned after the tag, e.g. @ignore should
>> be removed from compiler/5091921/Test7005594.java by the fix for
>> JDK-7117034:
>> test/compiler/5091921/Test7005594.java.html
>>>   28  * @ignore 7117034
>>
>> [1] http://openjdk.java.net/jtreg/tag-spec.txt
>>
>> Igor
>>
>> On 04/30/2014 09:53 PM, Vladimir Kozlov wrote:
>>> Igor,
>>>
>>> Please, explain the usage of @ignore tag.
>>> Will these tests run during nightly testing or not?
>>> How we know when the tag should be removed?
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 4/30/14 6:06 AM, Igor Ignatyev wrote:
>>>> http://cr.openjdk.java.net/~iignatyev/8042214/webrev.00/
>>>> 8 lines changed: 4 ins; 0 del; 4 mod;
>>>>
>>>> Hi all,
>>>>
>>>> Please review the patch which add @ignore tag to the tests which can
>>>> break test execution.
>>>>
>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8042214

From vladimir.kozlov at oracle.com  Thu May  1 17:52:29 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 01 May 2014 10:52:29 -0700
Subject: RFR (M): 8039298:  assert(base == NULL || t_adr->isa_rawptr() || ...
Message-ID: <536289DD.6010703@oracle.com>

http://cr.openjdk.java.net/~kvn/8039298/webrev
https://bugs.openjdk.java.net/browse/JDK-8039298

This assert was added for 6711117 when we observed "NULL+off" non-raw 
address type. It was fixed by delaying a memory node processing if its 
inputs are on IGVN worklist or address types do not match.

Recently we start hitting this assert for big graphs when control path 
become dead but due to the nodes order in IGVN worklist data nodes on 
dead path were processed first. As result we get TOP or NULL dead 
address base for memory nodes.

I am suggesting 2 ways solution.
First, convert the assert into the runtime check to skip IGVN 
optimizations for such memory nodes. I ran performance tests and did not 
see regression.
Second, eliminate dead nodes more aggressively. The method 
kill_dead_code() will eliminate dead loops (except irreducible), dead 
regions and nodes which have only TOP or NULL inputs. I have to add the 
code to mark presence of irreducible loops for that.

Test ctw, jtreg, jprt.

Thanks,
Vladimir

From morris.meyer at oracle.com  Thu May  1 18:34:28 2014
From: morris.meyer at oracle.com (Morris Meyer)
Date: Thu, 01 May 2014 14:34:28 -0400
Subject: RFR(XS): JDK-8040921: Uninitialised memory in
	hotspot/src/share/vm/c1/c1_LinearScan.cpp
In-Reply-To: <305D7E38-B9F1-4A89-8C92-805DFC62DA4B@oracle.com>
References: <53555C8D.7090406@oracle.com>
	<80C84BCB-1E02-4668-9B5C-7D351BB922E9@oracle.com>
	<53613588.8000306@oracle.com>
	<305D7E38-B9F1-4A89-8C92-805DFC62DA4B@oracle.com>
Message-ID: <536293B4.8040601@oracle.com>

The parfait error is with the ASSERT define blocking out initialization 
of a the fpu structures when that code path is enabled.

I've removed the ifdef such that both paths initialized their cpu and 
fpu variables, and the assertion is always checked.

--mm

On 4/30/14, 3:36 PM, Christian Thalinger wrote:
> I don?t understand the Parfait error here.  Could you explain?
>
> On Apr 30, 2014, at 7:40 AM, Morris Meyer <morris.meyer at oracle.com> wrote:
>
>> Folks,
>>
>> Could I get a review for this Parfait uninitialized variable issue? This has been tested with JPRT and a clear pass with Parfait.
>>
>> Thanks,
>>
>>         --mm
>>
>> BUG - https://bugs.openjdk.java.net/browse/JDK-8040921
>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.05
>>
>>


From christian.tornqvist at oracle.com  Thu May  1 19:04:08 2014
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Thu, 1 May 2014 15:04:08 -0400
Subject: RFR(XXS) : 8042214: add @ignore tag to all excluded jtreg tests
	in	test/compiler
In-Reply-To: <5360F543.1030208@oracle.com>
References: <5360F543.1030208@oracle.com>
Message-ID: <006301cf6570$21e23890$65a6a9b0$@oracle.com>

Hi Igor, 

The change looks good, thanks for doing this.

Thanks,
Christian

-----Original Message-----
From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Igor Ignatyev
Sent: Wednesday, April 30, 2014 9:06 AM
To: hotspot-compiler-dev at openjdk.java.net compiler
Subject: RFR(XXS) : 8042214: add @ignore tag to all excluded jtreg tests in test/compiler

http://cr.openjdk.java.net/~iignatyev/8042214/webrev.00/
8 lines changed: 4 ins; 0 del; 4 mod;

Hi all,

Please review the patch which add @ignore tag to the tests which can break test execution.

jbs: https://bugs.openjdk.java.net/browse/JDK-8042214
--
Igor


From vladimir.kozlov at oracle.com  Fri May  2 00:54:37 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 01 May 2014 17:54:37 -0700
Subject: RFR (XS) 8042281: compiler/7184394/TestAESMain.java fails with:
	javax.crypto.IllegalBlockSizeException
Message-ID: <5362ECCD.6010300@oracle.com>

http://cr.openjdk.java.net/~kvn/8042281/webrev/
https://bugs.openjdk.java.net/browse/JDK-8042281

Added missing -DmsgSize=640 to test's run commands.

Contributed-by: Shrinivas Joshi

From vladimir.kozlov at oracle.com  Fri May  2 00:59:13 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 01 May 2014 17:59:13 -0700
Subject: RFR (XS) 8042281: compiler/7184394/TestAESMain.java fails with:
	javax.crypto.IllegalBlockSizeException
In-Reply-To: <5362ECCD.6010300@oracle.com>
References: <5362ECCD.6010300@oracle.com>
Message-ID: <5362EDE1.60608@oracle.com>

Good :)

Vladimir

On 5/1/14 5:54 PM, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8042281/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8042281
>
> Added missing -DmsgSize=640 to test's run commands.
>
> Contributed-by: Shrinivas Joshi

From shrinivas.joshi at oracle.com  Fri May  2 01:07:37 2014
From: shrinivas.joshi at oracle.com (Shrinivas Joshi)
Date: Thu, 01 May 2014 18:07:37 -0700
Subject: RFR (XS) 8042281: compiler/7184394/TestAESMain.java fails with:
	javax.crypto.IllegalBlockSizeException
In-Reply-To: <5362EDE1.60608@oracle.com>
References: <5362ECCD.6010300@oracle.com> <5362EDE1.60608@oracle.com>
Message-ID: <5362EFD9.3000100@oracle.com>

Hi Vladimir,

Thanks again for your help with this. Sorry for the inconvenience with 
the back and forth on this change.

-Shrinivas

On 5/1/2014 5:59 PM, Vladimir Kozlov wrote:
> Good :)
>
> Vladimir
>
> On 5/1/14 5:54 PM, Vladimir Kozlov wrote:
>> http://cr.openjdk.java.net/~kvn/8042281/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8042281
>>
>> Added missing -DmsgSize=640 to test's run commands.
>>
>> Contributed-by: Shrinivas Joshi
>
>


From christian.thalinger at oracle.com  Fri May  2 01:51:00 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 1 May 2014 15:51:00 -1000
Subject: RFR(XS): JDK-8040921: Uninitialised memory in
	hotspot/src/share/vm/c1/c1_LinearScan.cpp
In-Reply-To: <536293B4.8040601@oracle.com>
References: <53555C8D.7090406@oracle.com>
	<80C84BCB-1E02-4668-9B5C-7D351BB922E9@oracle.com>
	<53613588.8000306@oracle.com>
	<305D7E38-B9F1-4A89-8C92-805DFC62DA4B@oracle.com>
	<536293B4.8040601@oracle.com>
Message-ID: <3723EF44-4D7B-4E12-AA83-45EF7DA8645B@oracle.com>


On May 1, 2014, at 8:34 AM, Morris Meyer <morris.meyer at oracle.com> wrote:

> The parfait error is with the ASSERT define blocking out initialization of a the fpu structures when that code path is enabled.
> 
> I've removed the ifdef such that both paths initialized their cpu and fpu variables, and the assertion is always checked.

But the code path using the uninitialized variables is also under:

1648   if (has_fpu_registers()) {

Am I missing something?  Anyway, during an earlier internal review I said we should keep the assert; I take that back.  We should move the variables and initialization down to the use and remove the assert.  It doesn?t have much value anyway.

> 
> --mm
> 
> On 4/30/14, 3:36 PM, Christian Thalinger wrote:
>> I don?t understand the Parfait error here.  Could you explain?
>> 
>> On Apr 30, 2014, at 7:40 AM, Morris Meyer <morris.meyer at oracle.com> wrote:
>> 
>>> Folks,
>>> 
>>> Could I get a review for this Parfait uninitialized variable issue? This has been tested with JPRT and a clear pass with Parfait.
>>> 
>>> Thanks,
>>> 
>>>        --mm
>>> 
>>> BUG - https://bugs.openjdk.java.net/browse/JDK-8040921
>>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-8040921.05
>>> 
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140501/644bbf51/attachment.html>

From christian.thalinger at oracle.com  Fri May  2 03:59:53 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 1 May 2014 17:59:53 -1000
Subject: RFR (M): 8039298: assert(base == NULL || t_adr->isa_rawptr() ||
	...
In-Reply-To: <536289DD.6010703@oracle.com>
References: <536289DD.6010703@oracle.com>
Message-ID: <8A3FDE47-F478-4FC2-883D-B2B3BD8DF3B7@oracle.com>

+                    use->is_Loop() && !use->is_Root() &&       // Root is also Loop
Is that correct?

On May 1, 2014, at 7:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> http://cr.openjdk.java.net/~kvn/8039298/webrev
> https://bugs.openjdk.java.net/browse/JDK-8039298
> 
> This assert was added for 6711117 when we observed "NULL+off" non-raw address type. It was fixed by delaying a memory node processing if its inputs are on IGVN worklist or address types do not match.
> 
> Recently we start hitting this assert for big graphs when control path become dead but due to the nodes order in IGVN worklist data nodes on dead path were processed first. As result we get TOP or NULL dead address base for memory nodes.
> 
> I am suggesting 2 ways solution.
> First, convert the assert into the runtime check to skip IGVN optimizations for such memory nodes. I ran performance tests and did not see regression.
> Second, eliminate dead nodes more aggressively. The method kill_dead_code() will eliminate dead loops (except irreducible), dead regions and nodes which have only TOP or NULL inputs. I have to add the code to mark presence of irreducible loops for that.
> 
> Test ctw, jtreg, jprt.
> 
> Thanks,
> Vladimir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140501/7263a90d/attachment.html>

From vladimir.kozlov at oracle.com  Fri May  2 04:25:38 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 01 May 2014 21:25:38 -0700
Subject: RFR (M): 8039298: assert(base == NULL || t_adr->isa_rawptr()
	|| ...
In-Reply-To: <8A3FDE47-F478-4FC2-883D-B2B3BD8DF3B7@oracle.com>
References: <536289DD.6010703@oracle.com>
	<8A3FDE47-F478-4FC2-883D-B2B3BD8DF3B7@oracle.com>
Message-ID: <53631E42.7080100@oracle.com>

On 5/1/14 8:59 PM, Christian Thalinger wrote:
> *+                    use->is_Loop() && !use->is_Root() &&       // Root is also Loop*
>
> Is that correct?

What do you mean?

class RootNode : public LoopNode {

And I don't want to kill Root.

Vladimir

>
> On May 1, 2014, at 7:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>
>> http://cr.openjdk.java.net/~kvn/8039298/webrev
>> https://bugs.openjdk.java.net/browse/JDK-8039298
>>
>> This assert was added for 6711117 when we observed "NULL+off" non-raw address type. It was fixed by delaying a memory
>> node processing if its inputs are on IGVN worklist or address types do not match.
>>
>> Recently we start hitting this assert for big graphs when control path become dead but due to the nodes order in IGVN
>> worklist data nodes on dead path were processed first. As result we get TOP or NULL dead address base for memory nodes.
>>
>> I am suggesting 2 ways solution.
>> First, convert the assert into the runtime check to skip IGVN optimizations for such memory nodes. I ran performance
>> tests and did not see regression.
>> Second, eliminate dead nodes more aggressively. The method kill_dead_code() will eliminate dead loops (except
>> irreducible), dead regions and nodes which have only TOP or NULL inputs. I have to add the code to mark presence of
>> irreducible loops for that.
>>
>> Test ctw, jtreg, jprt.
>>
>> Thanks,
>> Vladimir
>

From Tobias.Hartmann at oracle.com  Fri May  2 06:55:57 2014
From: Tobias.Hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 02 May 2014 08:55:57 +0200
Subject: [9] RFR(XS): 8042052: assert(t != NULL) failed: must set before
	get
In-Reply-To: <536114CA.8070304@oracle.com>
References: <536108FA.2070004@oracle.com> <536114CA.8070304@oracle.com>
Message-ID: <5363417D.5050609@oracle.com>

Hi Niclas,

thanks for the feedback. Please see comments inline.

On 04/30/2014 05:20 PM, Niclas Adlertz wrote:
> Hi Tobias,
>
> Thank you for catching this.
> I would say you can then change "_gvn.transform(result)" to just 
> "result" inside "inline_pow()", after the call to "finish_pow_exp()" 
> at line 1931:
>
> From:
> // the result from finish_pow_exp is now input to the phi node
>
>
> phi_node->init_req(2, _gvn.transform(result));
>
> To:
> phi_node->init_req(2, result);
>
> since "result" has already been returned from "_gvn.transform()" 
> either inside "finish_pow_exp" or before the call, inside "inline_pow()".

Done.

>
> Also since "_gvn.transform()" possibly returns a new node, this:
> // Make sure type of PhiNode is recorded
> _gvn.transform(result_val);
> return result_val;
>
> should be replaced with:
> return _gvn.transform(result_val);
>
> (I don't think the comment is nescessary since we need to record nodes 
> at many other places as well)

Yes, I missed that _gvn.transform(...) may return a new node. I changed 
the code according to your suggestions.

New webrev: http://cr.openjdk.java.net/~anoll/8042052/webrev.01/ 
<http://cr.openjdk.java.net/%7Eanoll/8042052/webrev.01/>

Thanks,
Tobias


>
> Kind Regards,
> Niclas Adlertz
>
> On 04/30/2014 04:30 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> please review the following patch for bug 8042052.
>>
>> *Problem*
>> The changes introduced by the fix for 8041912 [1] removed the call to
>> set_result(...) in LibraryCallKit::finish_pow_exp(...) that called
>> gvn.transform on the PhiNode results_val. The type of the PhiNode is
>> therefore not recorded in the gvn. The PhiNode is returned and later
>> accessed as an input to a StoreNode in
>> PhaseGVN::transform_no_reclaim(...). The call to StoreNode::Value tries
>> to look up the type of the PhiNode and triggers the assert in
>> PhaseTransform::type(...) because the type is not set.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042052
>>
>> *Solution*
>> A call to _gvn.transform is added to make sure the type of the PhiNode
>> is recorded.
>>
>> Webrev: http://cr.openjdk.java.net/~anoll/8042052/webrev.00/
>>
>> *Tests:*
>> Failing test (testMathExpDouble), JPRT
>>
>> Thanks,
>> Tobias
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8041912
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140502/44944209/attachment-0001.html>

From niclas.adlertz at oracle.com  Fri May  2 10:58:25 2014
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Fri, 02 May 2014 12:58:25 +0200
Subject: [9] RFR(XS): 8042052: assert(t != NULL) failed: must set before
	get
In-Reply-To: <5363417D.5050609@oracle.com>
References: <536108FA.2070004@oracle.com> <536114CA.8070304@oracle.com>
	<5363417D.5050609@oracle.com>
Message-ID: <53637A51.7040309@oracle.com>

That looks good to me.

Kind Regards,
Niclas Adlertz

On 05/02/2014 08:55 AM, Tobias Hartmann wrote:
> Hi Niclas,
>
> thanks for the feedback. Please see comments inline.
>
> On 04/30/2014 05:20 PM, Niclas Adlertz wrote:
>> Hi Tobias,
>>
>> Thank you for catching this.
>> I would say you can then change "_gvn.transform(result)" to just
>> "result" inside "inline_pow()", after the call to "finish_pow_exp()"
>> at line 1931:
>>
>> From:
>> // the result from finish_pow_exp is now input to the phi node
>>
>>
>> phi_node->init_req(2, _gvn.transform(result));
>>
>> To:
>> phi_node->init_req(2, result);
>>
>> since "result" has already been returned from "_gvn.transform()"
>> either inside "finish_pow_exp" or before the call, inside "inline_pow()".
>
> Done.
>
>>
>> Also since "_gvn.transform()" possibly returns a new node, this:
>> // Make sure type of PhiNode is recorded
>> _gvn.transform(result_val);
>> return result_val;
>>
>> should be replaced with:
>> return _gvn.transform(result_val);
>>
>> (I don't think the comment is nescessary since we need to record nodes
>> at many other places as well)
>
> Yes, I missed that _gvn.transform(...) may return a new node. I changed
> the code according to your suggestions.
>
> New webrev: http://cr.openjdk.java.net/~anoll/8042052/webrev.01/
> <http://cr.openjdk.java.net/%7Eanoll/8042052/webrev.01/>
>
> Thanks,
> Tobias
>
>
>>
>> Kind Regards,
>> Niclas Adlertz
>>
>> On 04/30/2014 04:30 PM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> please review the following patch for bug 8042052.
>>>
>>> *Problem*
>>> The changes introduced by the fix for 8041912 [1] removed the call to
>>> set_result(...) in LibraryCallKit::finish_pow_exp(...) that called
>>> gvn.transform on the PhiNode results_val. The type of the PhiNode is
>>> therefore not recorded in the gvn. The PhiNode is returned and later
>>> accessed as an input to a StoreNode in
>>> PhaseGVN::transform_no_reclaim(...). The call to StoreNode::Value tries
>>> to look up the type of the PhiNode and triggers the assert in
>>> PhaseTransform::type(...) because the type is not set.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042052
>>>
>>> *Solution*
>>> A call to _gvn.transform is added to make sure the type of the PhiNode
>>> is recorded.
>>>
>>> Webrev: http://cr.openjdk.java.net/~anoll/8042052/webrev.00/
>>>
>>> *Tests:*
>>> Failing test (testMathExpDouble), JPRT
>>>
>>> Thanks,
>>> Tobias
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8041912
>>>
>
>

From Tobias.Hartmann at oracle.com  Fri May  2 12:00:23 2014
From: Tobias.Hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 02 May 2014 14:00:23 +0200
Subject: [9] RFR(XS): 8042052: assert(t != NULL) failed: must set before
	get
In-Reply-To: <53637A51.7040309@oracle.com>
References: <536108FA.2070004@oracle.com> <536114CA.8070304@oracle.com>
	<5363417D.5050609@oracle.com> <53637A51.7040309@oracle.com>
Message-ID: <536388D7.5000706@oracle.com>

Thanks, Niclas.

Tobias

On 05/02/2014 12:58 PM, Niclas Adlertz wrote:
> That looks good to me.
>
> Kind Regards,
> Niclas Adlertz
>
> On 05/02/2014 08:55 AM, Tobias Hartmann wrote:
>> Hi Niclas,
>>
>> thanks for the feedback. Please see comments inline.
>>
>> On 04/30/2014 05:20 PM, Niclas Adlertz wrote:
>>> Hi Tobias,
>>>
>>> Thank you for catching this.
>>> I would say you can then change "_gvn.transform(result)" to just
>>> "result" inside "inline_pow()", after the call to "finish_pow_exp()"
>>> at line 1931:
>>>
>>> From:
>>> // the result from finish_pow_exp is now input to the phi node
>>>
>>>
>>> phi_node->init_req(2, _gvn.transform(result));
>>>
>>> To:
>>> phi_node->init_req(2, result);
>>>
>>> since "result" has already been returned from "_gvn.transform()"
>>> either inside "finish_pow_exp" or before the call, inside 
>>> "inline_pow()".
>>
>> Done.
>>
>>>
>>> Also since "_gvn.transform()" possibly returns a new node, this:
>>> // Make sure type of PhiNode is recorded
>>> _gvn.transform(result_val);
>>> return result_val;
>>>
>>> should be replaced with:
>>> return _gvn.transform(result_val);
>>>
>>> (I don't think the comment is nescessary since we need to record nodes
>>> at many other places as well)
>>
>> Yes, I missed that _gvn.transform(...) may return a new node. I changed
>> the code according to your suggestions.
>>
>> New webrev: http://cr.openjdk.java.net/~anoll/8042052/webrev.01/
>> <http://cr.openjdk.java.net/%7Eanoll/8042052/webrev.01/>
>>
>> Thanks,
>> Tobias
>>
>>
>>>
>>> Kind Regards,
>>> Niclas Adlertz
>>>
>>> On 04/30/2014 04:30 PM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> please review the following patch for bug 8042052.
>>>>
>>>> *Problem*
>>>> The changes introduced by the fix for 8041912 [1] removed the call to
>>>> set_result(...) in LibraryCallKit::finish_pow_exp(...) that called
>>>> gvn.transform on the PhiNode results_val. The type of the PhiNode is
>>>> therefore not recorded in the gvn. The PhiNode is returned and later
>>>> accessed as an input to a StoreNode in
>>>> PhaseGVN::transform_no_reclaim(...). The call to StoreNode::Value 
>>>> tries
>>>> to look up the type of the PhiNode and triggers the assert in
>>>> PhaseTransform::type(...) because the type is not set.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042052
>>>>
>>>> *Solution*
>>>> A call to _gvn.transform is added to make sure the type of the PhiNode
>>>> is recorded.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~anoll/8042052/webrev.00/
>>>>
>>>> *Tests:*
>>>> Failing test (testMathExpDouble), JPRT
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8041912
>>>>
>>
>>


From Tobias.Hartmann at oracle.com  Fri May  2 12:15:39 2014
From: Tobias.Hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 02 May 2014 14:15:39 +0200
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
Message-ID: <53638C6B.10600@oracle.com>

Hi,

please review the following patch for bug 8036851.

*Problem*
Volatile double accesses are not treated different from normal accesses 
in the C2 compiler with respect to atomicity because on x86 and sparc 
double accesses were always atomic. However, this may not be case on 
other architectures. On an architecture where there are atomic and 
non-atomic double accesses, we would have to implement all accesses to 
be atomic, because the C2 compiler does not distinguish between the two 
cases.
Bug: https://bugs.openjdk.java.net/browse/JDK-8036851

*Solution*
The C2 structure is adapted to distinguish between volatile and 
non-volatile double accesses.
Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/ 
<http://cr.openjdk.java.net/%7Eanoll/8036851/webrev.00/>

*Tests*
JPRT

Thanks,
Tobias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140502/e82254a0/attachment.html>

From aleksey.shipilev at oracle.com  Fri May  2 13:53:24 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 02 May 2014 17:53:24 +0400
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <53638C6B.10600@oracle.com>
References: <53638C6B.10600@oracle.com>
Message-ID: <5363A354.9010801@oracle.com>

Glad to see this addressed. The patch looks fine to me (not a Reviewer).

I remember seeing places in C1 where we special-case T_LONG, so we
probably need an additional work to fix it there as well. See e.g.
LIRGenerator::volatile_field_store.

-Aleksey

On 05/02/2014 04:15 PM, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch for bug 8036851.
> 
> *Problem*
> Volatile double accesses are not treated different from normal accesses
> in the C2 compiler with respect to atomicity because on x86 and sparc
> double accesses were always atomic. However, this may not be case on
> other architectures. On an architecture where there are atomic and
> non-atomic double accesses, we would have to implement all accesses to
> be atomic, because the C2 compiler does not distinguish between the two
> cases.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
> 
> *Solution*
> The C2 structure is adapted to distinguish between volatile and
> non-volatile double accesses.
> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/
> <http://cr.openjdk.java.net/%7Eanoll/8036851/webrev.00/>
> 
> *Tests*
> JPRT
> 
> Thanks,
> Tobias
> 


From aph at redhat.com  Fri May  2 14:21:57 2014
From: aph at redhat.com (Andrew Haley)
Date: Fri, 02 May 2014 15:21:57 +0100
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <5363A354.9010801@oracle.com>
References: <53638C6B.10600@oracle.com> <5363A354.9010801@oracle.com>
Message-ID: <5363AA05.2080905@redhat.com>

On 05/02/2014 02:53 PM, Aleksey Shipilev wrote:
> Glad to see this addressed. The patch looks fine to me (not a Reviewer).
> 
> I remember seeing places in C1 where we special-case T_LONG, so we
> probably need an additional work to fix it there as well. See e.g.
> LIRGenerator::volatile_field_store.

How on Earth does this work in the back end on a 32-bit box without 64-bit
operations?  Do you have to use a lock, and how does clone() work in that
case?

Andrew.


From Tobias.Hartmann at oracle.com  Fri May  2 15:09:21 2014
From: Tobias.Hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 02 May 2014 17:09:21 +0200
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <5363A354.9010801@oracle.com>
References: <53638C6B.10600@oracle.com> <5363A354.9010801@oracle.com>
Message-ID: <5363B521.3060806@oracle.com>

Hi Aleksey,

thanks for your feedback.

On 05/02/2014 03:53 PM, Aleksey Shipilev wrote:
> Glad to see this addressed. The patch looks fine to me (not a Reviewer).
>
> I remember seeing places in C1 where we special-case T_LONG, so we
> probably need an additional work to fix it there as well. See e.g.
> LIRGenerator::volatile_field_store.

But the implementation of LIRGenerator::volatile_field_store is 
architecture specific so it should be fine to special-case T_LONG on x86 
because all other accesses are guaranteed to be atomic. Or am I missing 
something here?

Thanks,
Tobias

>
> -Aleksey
>
> On 05/02/2014 04:15 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> please review the following patch for bug 8036851.
>>
>> *Problem*
>> Volatile double accesses are not treated different from normal accesses
>> in the C2 compiler with respect to atomicity because on x86 and sparc
>> double accesses were always atomic. However, this may not be case on
>> other architectures. On an architecture where there are atomic and
>> non-atomic double accesses, we would have to implement all accesses to
>> be atomic, because the C2 compiler does not distinguish between the two
>> cases.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
>>
>> *Solution*
>> The C2 structure is adapted to distinguish between volatile and
>> non-volatile double accesses.
>> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/
>> <http://cr.openjdk.java.net/%7Eanoll/8036851/webrev.00/>
>>
>> *Tests*
>> JPRT
>>
>> Thanks,
>> Tobias
>>


From aleksey.shipilev at oracle.com  Fri May  2 15:17:18 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 02 May 2014 19:17:18 +0400
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <5363B521.3060806@oracle.com>
References: <53638C6B.10600@oracle.com> <5363A354.9010801@oracle.com>
	<5363B521.3060806@oracle.com>
Message-ID: <5363B6FE.3080005@oracle.com>

On 05/02/2014 07:09 PM, Tobias Hartmann wrote:
> On 05/02/2014 03:53 PM, Aleksey Shipilev wrote:
>> I remember seeing places in C1 where we special-case T_LONG, so we
>> probably need an additional work to fix it there as well. See e.g.
>> LIRGenerator::volatile_field_store.
> 
> But the implementation of LIRGenerator::volatile_field_store is
> architecture specific so it should be fine to special-case T_LONG on x86
> because all other accesses are guaranteed to be atomic. Or am I missing
> something here?

Right. This is for x86, so no problem there.

-Aleksey.


From aleksey.shipilev at oracle.com  Fri May  2 15:29:27 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 02 May 2014 19:29:27 +0400
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <5363AA05.2080905@redhat.com>
References: <53638C6B.10600@oracle.com> <5363A354.9010801@oracle.com>
	<5363AA05.2080905@redhat.com>
Message-ID: <5363B9D7.8070101@oracle.com>

On 05/02/2014 06:21 PM, Andrew Haley wrote:
> On 05/02/2014 02:53 PM, Aleksey Shipilev wrote:
>> Glad to see this addressed. The patch looks fine to me (not a Reviewer).
>>
>> I remember seeing places in C1 where we special-case T_LONG, so we
>> probably need an additional work to fix it there as well. See e.g.
>> LIRGenerator::volatile_field_store.
> 
> How on Earth does this work in the back end on a 32-bit box without 64-bit
> operations?  Do you have to use a lock, and how does clone() work in that
> case?

I think most supported platforms support 64-bit instructions in one
sense or the other. For 32-bit x86, there's still FPU -- and this is
what volatile_field_store on x86 does. The relevant backend
implementation should care how to implement volatile_field_store on
specific platform (I was deluded in thinking the special T_LONG case was
in platform-independent code, but it really is for x86 only).

-Aleksey.

From vladimir.kozlov at oracle.com  Fri May  2 17:31:47 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 02 May 2014 10:31:47 -0700
Subject: [9] RFR(XS): 8042052: assert(t != NULL) failed: must set before
	get
In-Reply-To: <5363417D.5050609@oracle.com>
References: <536108FA.2070004@oracle.com> <536114CA.8070304@oracle.com>
	<5363417D.5050609@oracle.com>
Message-ID: <5363D683.4000007@oracle.com>

This looks good.

thanks,
Vladimir

On 5/1/14 11:55 PM, Tobias Hartmann wrote:
> Hi Niclas,
>
> thanks for the feedback. Please see comments inline.
>
> On 04/30/2014 05:20 PM, Niclas Adlertz wrote:
>> Hi Tobias,
>>
>> Thank you for catching this.
>> I would say you can then change "_gvn.transform(result)" to just "result" inside "inline_pow()", after the call to
>> "finish_pow_exp()" at line 1931:
>>
>> From:
>> // the result from finish_pow_exp is now input to the phi node
>>
>>
>> phi_node->init_req(2, _gvn.transform(result));
>>
>> To:
>> phi_node->init_req(2, result);
>>
>> since "result" has already been returned from "_gvn.transform()" either inside "finish_pow_exp" or before the call,
>> inside "inline_pow()".
>
> Done.
>
>>
>> Also since "_gvn.transform()" possibly returns a new node, this:
>> // Make sure type of PhiNode is recorded
>> _gvn.transform(result_val);
>> return result_val;
>>
>> should be replaced with:
>> return _gvn.transform(result_val);
>>
>> (I don't think the comment is nescessary since we need to record nodes at many other places as well)
>
> Yes, I missed that _gvn.transform(...) may return a new node. I changed the code according to your suggestions.
>
> New webrev: http://cr.openjdk.java.net/~anoll/8042052/webrev.01/ <http://cr.openjdk.java.net/%7Eanoll/8042052/webrev.01/>
>
> Thanks,
> Tobias
>
>
>>
>> Kind Regards,
>> Niclas Adlertz
>>
>> On 04/30/2014 04:30 PM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> please review the following patch for bug 8042052.
>>>
>>> *Problem*
>>> The changes introduced by the fix for 8041912 [1] removed the call to
>>> set_result(...) in LibraryCallKit::finish_pow_exp(...) that called
>>> gvn.transform on the PhiNode results_val. The type of the PhiNode is
>>> therefore not recorded in the gvn. The PhiNode is returned and later
>>> accessed as an input to a StoreNode in
>>> PhaseGVN::transform_no_reclaim(...). The call to StoreNode::Value tries
>>> to look up the type of the PhiNode and triggers the assert in
>>> PhaseTransform::type(...) because the type is not set.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042052
>>>
>>> *Solution*
>>> A call to _gvn.transform is added to make sure the type of the PhiNode
>>> is recorded.
>>>
>>> Webrev: http://cr.openjdk.java.net/~anoll/8042052/webrev.00/
>>>
>>> *Tests:*
>>> Failing test (testMathExpDouble), JPRT
>>>
>>> Thanks,
>>> Tobias
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8041912
>>>
>

From christian.thalinger at oracle.com  Fri May  2 19:09:47 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 2 May 2014 09:09:47 -1000
Subject: RFR (M): 8039298: assert(base == NULL || t_adr->isa_rawptr() ||
	...
In-Reply-To: <53631E42.7080100@oracle.com>
References: <536289DD.6010703@oracle.com>
	<8A3FDE47-F478-4FC2-883D-B2B3BD8DF3B7@oracle.com>
	<53631E42.7080100@oracle.com>
Message-ID: <DF109498-4AF4-411D-B490-E795B56B447E@oracle.com>


On May 1, 2014, at 6:25 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> On 5/1/14 8:59 PM, Christian Thalinger wrote:
>> *+                    use->is_Loop() && !use->is_Root() &&       // Root is also Loop*
>> 
>> Is that correct?
> 
> What do you mean?
> 
> class RootNode : public LoopNode {

Ah, got it.  I was confused by the comment.  It actually says that RootNode extends LoopNode.  Then it looks good.

> 
> And I don't want to kill Root.
> 
> Vladimir
> 
>> 
>> On May 1, 2014, at 7:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>> 
>>> http://cr.openjdk.java.net/~kvn/8039298/webrev
>>> https://bugs.openjdk.java.net/browse/JDK-8039298
>>> 
>>> This assert was added for 6711117 when we observed "NULL+off" non-raw address type. It was fixed by delaying a memory
>>> node processing if its inputs are on IGVN worklist or address types do not match.
>>> 
>>> Recently we start hitting this assert for big graphs when control path become dead but due to the nodes order in IGVN
>>> worklist data nodes on dead path were processed first. As result we get TOP or NULL dead address base for memory nodes.
>>> 
>>> I am suggesting 2 ways solution.
>>> First, convert the assert into the runtime check to skip IGVN optimizations for such memory nodes. I ran performance
>>> tests and did not see regression.
>>> Second, eliminate dead nodes more aggressively. The method kill_dead_code() will eliminate dead loops (except
>>> irreducible), dead regions and nodes which have only TOP or NULL inputs. I have to add the code to mark presence of
>>> irreducible loops for that.
>>> 
>>> Test ctw, jtreg, jprt.
>>> 
>>> Thanks,
>>> Vladimir
>> 


From christian.thalinger at oracle.com  Fri May  2 19:23:46 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 2 May 2014 09:23:46 -1000
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <53638C6B.10600@oracle.com>
References: <53638C6B.10600@oracle.com>
Message-ID: <212507C6-507A-4813-B796-42413A5D9A14@oracle.com>

src/share/vm/opto/memnode.hpp:

+   #ifndef PRODUCT
+     virtual void dump_spec(outputStream *st) const {
+       LoadNode::dump_spec(st);
+       if (_require_atomic_access)  st->print(" Atomic!");
+     }
+   #endif

Indent is wrong.

Otherwise this looks good.

On May 2, 2014, at 2:15 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi,
> 
> please review the following patch for bug 8036851.
> 
> Problem
> Volatile double accesses are not treated different from normal accesses in the C2 compiler with respect to atomicity because on x86 and sparc double accesses were always atomic. However, this may not be case on other architectures. On an architecture where there are atomic and non-atomic double accesses, we would have to implement all accesses to be atomic, because the C2 compiler does not distinguish between the two cases.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
> 
> Solution
> The C2 structure is adapted to distinguish between volatile and non-volatile double accesses.
> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/
> 
> Tests
> JPRT
> 
> Thanks,
> Tobias
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140502/046e34b4/attachment.html>

From christian.thalinger at oracle.com  Fri May  2 19:23:46 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 2 May 2014 09:23:46 -1000
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <53638C6B.10600@oracle.com>
References: <53638C6B.10600@oracle.com>
Message-ID: <212507C6-507A-4813-B796-42413A5D9A14@oracle.com>

src/share/vm/opto/memnode.hpp:

+   #ifndef PRODUCT
+     virtual void dump_spec(outputStream *st) const {
+       LoadNode::dump_spec(st);
+       if (_require_atomic_access)  st->print(" Atomic!");
+     }
+   #endif

Indent is wrong.

Otherwise this looks good.

On May 2, 2014, at 2:15 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi,
> 
> please review the following patch for bug 8036851.
> 
> Problem
> Volatile double accesses are not treated different from normal accesses in the C2 compiler with respect to atomicity because on x86 and sparc double accesses were always atomic. However, this may not be case on other architectures. On an architecture where there are atomic and non-atomic double accesses, we would have to implement all accesses to be atomic, because the C2 compiler does not distinguish between the two cases.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
> 
> Solution
> The C2 structure is adapted to distinguish between volatile and non-volatile double accesses.
> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/
> 
> Tests
> JPRT
> 
> Thanks,
> Tobias
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140502/046e34b4/attachment-0001.html>

From vladimir.kozlov at oracle.com  Fri May  2 19:46:31 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 02 May 2014 12:46:31 -0700
Subject: RFR (M): 8039298: assert(base == NULL || t_adr->isa_rawptr()
	|| ...
In-Reply-To: <DF109498-4AF4-411D-B490-E795B56B447E@oracle.com>
References: <536289DD.6010703@oracle.com>
	<8A3FDE47-F478-4FC2-883D-B2B3BD8DF3B7@oracle.com>
	<53631E42.7080100@oracle.com>
	<DF109498-4AF4-411D-B490-E795B56B447E@oracle.com>
Message-ID: <5363F617.2020300@oracle.com>

Thank you, Christian

I will correct the comment to avoid a confusion:

  // Don't kill Root (RootNode extends LoopNode)

Thanks,
Vladimir

On 5/2/14 12:09 PM, Christian Thalinger wrote:
>
> On May 1, 2014, at 6:25 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> On 5/1/14 8:59 PM, Christian Thalinger wrote:
>>> *+                    use->is_Loop() && !use->is_Root() &&       // Root is also Loop*
>>>
>>> Is that correct?
>>
>> What do you mean?
>>
>> class RootNode : public LoopNode {
>
> Ah, got it.  I was confused by the comment.  It actually says that RootNode extends LoopNode.  Then it looks good.
>
>>
>> And I don't want to kill Root.
>>
>> Vladimir
>>
>>>
>>> On May 1, 2014, at 7:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>
>>>> http://cr.openjdk.java.net/~kvn/8039298/webrev
>>>> https://bugs.openjdk.java.net/browse/JDK-8039298
>>>>
>>>> This assert was added for 6711117 when we observed "NULL+off" non-raw address type. It was fixed by delaying a memory
>>>> node processing if its inputs are on IGVN worklist or address types do not match.
>>>>
>>>> Recently we start hitting this assert for big graphs when control path become dead but due to the nodes order in IGVN
>>>> worklist data nodes on dead path were processed first. As result we get TOP or NULL dead address base for memory nodes.
>>>>
>>>> I am suggesting 2 ways solution.
>>>> First, convert the assert into the runtime check to skip IGVN optimizations for such memory nodes. I ran performance
>>>> tests and did not see regression.
>>>> Second, eliminate dead nodes more aggressively. The method kill_dead_code() will eliminate dead loops (except
>>>> irreducible), dead regions and nodes which have only TOP or NULL inputs. I have to add the code to mark presence of
>>>> irreducible loops for that.
>>>>
>>>> Test ctw, jtreg, jprt.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>
>

From igor.veresov at oracle.com  Fri May  2 23:36:38 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Fri, 2 May 2014 16:36:38 -0700
Subject: RFR (M): 8039298: assert(base == NULL || t_adr->isa_rawptr() ||
	...
In-Reply-To: <536289DD.6010703@oracle.com>
References: <536289DD.6010703@oracle.com>
Message-ID: <005DFEB2-04FD-46F9-ABD6-65ED85D1D289@oracle.com>

Looks good.

igor

On May 1, 2014, at 10:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> http://cr.openjdk.java.net/~kvn/8039298/webrev
> https://bugs.openjdk.java.net/browse/JDK-8039298
> 
> This assert was added for 6711117 when we observed "NULL+off" non-raw address type. It was fixed by delaying a memory node processing if its inputs are on IGVN worklist or address types do not match.
> 
> Recently we start hitting this assert for big graphs when control path become dead but due to the nodes order in IGVN worklist data nodes on dead path were processed first. As result we get TOP or NULL dead address base for memory nodes.
> 
> I am suggesting 2 ways solution.
> First, convert the assert into the runtime check to skip IGVN optimizations for such memory nodes. I ran performance tests and did not see regression.
> Second, eliminate dead nodes more aggressively. The method kill_dead_code() will eliminate dead loops (except irreducible), dead regions and nodes which have only TOP or NULL inputs. I have to add the code to mark presence of irreducible loops for that.
> 
> Test ctw, jtreg, jprt.
> 
> Thanks,
> Vladimir


From vladimir.kozlov at oracle.com  Fri May  2 23:42:27 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 02 May 2014 16:42:27 -0700
Subject: RFR (M): 8039298: assert(base == NULL || t_adr->isa_rawptr()
	|| ...
In-Reply-To: <005DFEB2-04FD-46F9-ABD6-65ED85D1D289@oracle.com>
References: <536289DD.6010703@oracle.com>
	<005DFEB2-04FD-46F9-ABD6-65ED85D1D289@oracle.com>
Message-ID: <53642D63.80304@oracle.com>

Thank you, Igor

Vladimir

On 5/2/14 4:36 PM, Igor Veresov wrote:
> Looks good.
>
> igor
>
> On May 1, 2014, at 10:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> http://cr.openjdk.java.net/~kvn/8039298/webrev
>> https://bugs.openjdk.java.net/browse/JDK-8039298
>>
>> This assert was added for 6711117 when we observed "NULL+off" non-raw address type. It was fixed by delaying a memory node processing if its inputs are on IGVN worklist or address types do not match.
>>
>> Recently we start hitting this assert for big graphs when control path become dead but due to the nodes order in IGVN worklist data nodes on dead path were processed first. As result we get TOP or NULL dead address base for memory nodes.
>>
>> I am suggesting 2 ways solution.
>> First, convert the assert into the runtime check to skip IGVN optimizations for such memory nodes. I ran performance tests and did not see regression.
>> Second, eliminate dead nodes more aggressively. The method kill_dead_code() will eliminate dead loops (except irreducible), dead regions and nodes which have only TOP or NULL inputs. I have to add the code to mark presence of irreducible loops for that.
>>
>> Test ctw, jtreg, jprt.
>>
>> Thanks,
>> Vladimir
>

From david.holmes at oracle.com  Sun May  4 20:14:26 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 05 May 2014 06:14:26 +1000
Subject: RFR (XS) JDK-8041627: Solaris Studio 12.4 C++ 5.13 compilation
	error due to lack of "surplus" prototype for binaryTreeDictionary.cpp
In-Reply-To: <53668E76.9070601@oracle.com>
References: <53668E76.9070601@oracle.com>
Message-ID: <53669FA2.5040501@oracle.com>

Hi Lois,

On 5/05/2014 5:01 AM, Lois Foltan wrote:
> Hello,
>
> Please review the following fix:
>
> Webrev:
>      http://cr.openjdk.java.net/~lfoltan/bug_jdk8041627
>
> Bug: Solaris Studio 12.4 C++ 5.13 compilation error due to lack of
> "surplus" prototype for binaryTreeDictionary.cpp
>      https://bugs.openjdk.java.net/browse/JDK-8041627
>
> Summary:
> Thank you to Christian Thalinger for posting the code fix for this
> issue.  Solaris Studio 12.4 C++ 5.13
> generates the following compilation error diagnostic concerning the use
> of "surplus" at line 123:
> "<directory>/src/share/vm/memory/binaryTreeDictionary.cpp", line 123:
> Error: The function "surplus" must have a prototype

Curious error message (to me).

Fix looks fine. Hopefully this is the last such change to be made to 
this code.

David
-----

> Tests:
> JPRT build & test, Hotspot's JTREG test system, vm.quick.testlist

From david.holmes at oracle.com  Sun May  4 20:20:26 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 05 May 2014 06:20:26 +1000
Subject: RFR (S) JDK-8041620: Solaris Studio 12.4 C++ 5.13 change in
	behavior for placing friend declarations within surrounding scope
In-Reply-To: <53669162.9080500@oracle.com>
References: <53669162.9080500@oracle.com>
Message-ID: <5366A10A.7000109@oracle.com>

Hi Lois,

Deletion of FileBuffRegion looks okay to me.

Otherwise would the fix have been to change

friend ostream& operator<< (ostream&, FileBuffRegion&);

to

friend ostream& ::std::operator<< (ostream&, FileBuffRegion&);

?

Thanks,
David

On 5/05/2014 5:13 AM, Lois Foltan wrote:
> Hello,
>
> Please review the following fix:
>
> Webrev:
>      http://cr.openjdk.java.net/~lfoltan/bug_jdk8041620/
>
> Bug: Solaris Studio 12.4 C++ 5.13 change in behavior for placing friend
> declarations within surrounding scope
>      https://bugs.openjdk.java.net/browse/JDK-8041620
>
> Summary:
> Solaris Studio 12.4 C++ 5.13 compiler generates the following warning
> level compilation diagnostic for
> adlc/filebuff.hpp:
>
> "<directory>/src/share/vm/adlc/filebuff.hpp", line 107: Error:
> Unqualified name '<<' in friend declaration is looked up in the nearest
> enclosing namespace and does not refer to existing
> '::std::operator<<<_charT, _Traits>(basic_ostream<_charT, _Traits>&,
> _charT)'.
> 1 Error(s) detected.
>
> C++ 5.13 external beta documentation at
> http://docs.oracle.com/cd/E37069_01/html/E37075/gnyjb.html#OSSCPgnyly,
> details this change in behavior for friend declarations.  Thank you to
> Christian Thalinger for pointing out that
> within filebuff.hpp, class FileBuffRegion is no longer used. Instead of
> fixing the friend declaration in unused code,
> removing FileBuffRegion.
>
> Tests:
> JPRT build & test, Hotspot's JTREG test system, vm.quick.testlist

From lois.foltan at oracle.com  Sun May  4 19:01:10 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Sun, 04 May 2014 15:01:10 -0400
Subject: RFR (XS) JDK-8041627: Solaris Studio 12.4 C++ 5.13 compilation error
	due to lack of "surplus" prototype for binaryTreeDictionary.cpp
Message-ID: <53668E76.9070601@oracle.com>

Hello,

Please review the following fix:

Webrev:
     http://cr.openjdk.java.net/~lfoltan/bug_jdk8041627

Bug: Solaris Studio 12.4 C++ 5.13 compilation error due to lack of 
"surplus" prototype for binaryTreeDictionary.cpp
     https://bugs.openjdk.java.net/browse/JDK-8041627

Summary:
Thank you to Christian Thalinger for posting the code fix for this 
issue.  Solaris Studio 12.4 C++ 5.13
generates the following compilation error diagnostic concerning the use 
of "surplus" at line 123:
"<directory>/src/share/vm/memory/binaryTreeDictionary.cpp", line 123: 
Error: The function "surplus" must have a prototype

Tests:
JPRT build & test, Hotspot's JTREG test system, vm.quick.testlist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140504/a3e077ff/attachment.html>

From lois.foltan at oracle.com  Sun May  4 19:13:38 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Sun, 04 May 2014 15:13:38 -0400
Subject: RFR (S) JDK-8041620: Solaris Studio 12.4 C++ 5.13 change in behavior
	for placing friend declarations within surrounding scope
Message-ID: <53669162.9080500@oracle.com>

Hello,

Please review the following fix:

Webrev:
     http://cr.openjdk.java.net/~lfoltan/bug_jdk8041620/

Bug: Solaris Studio 12.4 C++ 5.13 change in behavior for placing friend 
declarations within surrounding scope
     https://bugs.openjdk.java.net/browse/JDK-8041620

Summary:
Solaris Studio 12.4 C++ 5.13 compiler generates the following warning 
level compilation diagnostic for
adlc/filebuff.hpp:

"<directory>/src/share/vm/adlc/filebuff.hpp", line 107: Error: 
Unqualified name '<<' in friend declaration is looked up in the nearest 
enclosing namespace and does not refer to existing 
'::std::operator<<<_charT, _Traits>(basic_ostream<_charT, _Traits>&, 
_charT)'.
1 Error(s) detected.

C++ 5.13 external beta documentation at 
http://docs.oracle.com/cd/E37069_01/html/E37075/gnyjb.html#OSSCPgnyly,
details this change in behavior for friend declarations.  Thank you to 
Christian Thalinger for pointing out that
within filebuff.hpp, class FileBuffRegion is no longer used. Instead of 
fixing the friend declaration in unused code,
removing FileBuffRegion.

Tests:
JPRT build & test, Hotspot's JTREG test system, vm.quick.testlist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140504/0a63ae06/attachment.html>

From Tobias.Hartmann at oracle.com  Mon May  5 07:02:44 2014
From: Tobias.Hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 05 May 2014 09:02:44 +0200
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <212507C6-507A-4813-B796-42413A5D9A14@oracle.com>
References: <53638C6B.10600@oracle.com>
	<212507C6-507A-4813-B796-42413A5D9A14@oracle.com>
Message-ID: <53673794.20809@oracle.com>

Hi Christian,

thanks for the review.

On 05/02/2014 09:23 PM, Christian Thalinger wrote:
> *src/share/vm/opto/memnode.hpp:*
> *
> *
> *+   #ifndef PRODUCT*
> *+     virtual void dump_spec(outputStream *st) const {*
> *+       LoadNode::dump_spec(st);*
> *+       if (_require_atomic_access)  st->print(" Atomic!");*
> *+     }*
> *+   #endif*
>
> Indent is wrong.

I missed that, thanks!

New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.01/

Best regards,
Tobias

>
> Otherwise this looks good.
>
> On May 2, 2014, at 2:15 AM, Tobias Hartmann 
> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>
>> Hi,
>>
>> please review the following patch for bug 8036851.
>>
>> *Problem*
>> Volatile double accesses are not treated different from normal 
>> accesses in the C2 compiler with respect to atomicity because on x86 
>> and sparc double accesses were always atomic. However, this may not 
>> be case on other architectures. On an architecture where there are 
>> atomic and non-atomic double accesses, we would have to implement all 
>> accesses to be atomic, because the C2 compiler does not distinguish 
>> between the two cases.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
>>
>> *Solution*
>> The C2 structure is adapted to distinguish between volatile and 
>> non-volatile double accesses.
>> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eanoll/8036851/webrev.00/>
>>
>> *Tests*
>> JPRT
>>
>> Thanks,
>> Tobias
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140505/4c7bec24/attachment-0001.html>

From niclas.adlertz at oracle.com  Mon May  5 08:31:12 2014
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Mon, 05 May 2014 10:31:12 +0200
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <53673794.20809@oracle.com>
References: <53638C6B.10600@oracle.com>	<212507C6-507A-4813-B796-42413A5D9A14@oracle.com>
	<53673794.20809@oracle.com>
Message-ID: <53674C50.4010008@oracle.com>

Minor thing:
bool require_atomic_access()       { return _require_atomic_access; }
could be defined as:
bool require_atomic_access() const { return _require_atomic_access; }

You could also change that for LoadL/StoreL while you are at it :)

Kind Regards,
Niclas Adlertz

On 05/05/2014 09:02 AM, Tobias Hartmann wrote:
> Hi Christian,
>
> thanks for the review.
>
> On 05/02/2014 09:23 PM, Christian Thalinger wrote:
>> *src/share/vm/opto/memnode.hpp:*
>> *
>> *
>> *+   #ifndef PRODUCT*
>> *+     virtual void dump_spec(outputStream *st) const {*
>> *+       LoadNode::dump_spec(st);*
>> *+       if (_require_atomic_access)  st->print(" Atomic!");*
>> *+     }*
>> *+   #endif*
>>
>> Indent is wrong.
>
> I missed that, thanks!
>
> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.01/
>
> Best regards,
> Tobias
>
>>
>> Otherwise this looks good.
>>
>> On May 2, 2014, at 2:15 AM, Tobias Hartmann
>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>
>>> Hi,
>>>
>>> please review the following patch for bug 8036851.
>>>
>>> *Problem*
>>> Volatile double accesses are not treated different from normal
>>> accesses in the C2 compiler with respect to atomicity because on x86
>>> and sparc double accesses were always atomic. However, this may not
>>> be case on other architectures. On an architecture where there are
>>> atomic and non-atomic double accesses, we would have to implement all
>>> accesses to be atomic, because the C2 compiler does not distinguish
>>> between the two cases.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
>>>
>>> *Solution*
>>> The C2 structure is adapted to distinguish between volatile and
>>> non-volatile double accesses.
>>> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/
>>> <http://cr.openjdk.java.net/%7Eanoll/8036851/webrev.00/>
>>>
>>> *Tests*
>>> JPRT
>>>
>>> Thanks,
>>> Tobias
>>>
>>
>
>

From tobias.hartmann at oracle.com  Mon May  5 10:54:37 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 05 May 2014 12:54:37 +0200
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <53674C50.4010008@oracle.com>
References: <53638C6B.10600@oracle.com>	<212507C6-507A-4813-B796-42413A5D9A14@oracle.com>
	<53673794.20809@oracle.com> <53674C50.4010008@oracle.com>
Message-ID: <53676DED.4030807@oracle.com>

Hi Niclas,

thanks for the feedback.

On 05.05.2014 10:31, Niclas Adlertz wrote:
> Minor thing:
> bool require_atomic_access()       { return _require_atomic_access; }
> could be defined as:
> bool require_atomic_access() const { return _require_atomic_access; }
>
> You could also change that for LoadL/StoreL while you are at it :)

Done.

New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.02/

Thanks,
Tobias

>
> Kind Regards,
> Niclas Adlertz
>
> On 05/05/2014 09:02 AM, Tobias Hartmann wrote:
>> Hi Christian,
>>
>> thanks for the review.
>>
>> On 05/02/2014 09:23 PM, Christian Thalinger wrote:
>>> *src/share/vm/opto/memnode.hpp:*
>>> *
>>> *
>>> *+   #ifndef PRODUCT*
>>> *+     virtual void dump_spec(outputStream *st) const {*
>>> *+       LoadNode::dump_spec(st);*
>>> *+       if (_require_atomic_access)  st->print(" Atomic!");*
>>> *+     }*
>>> *+   #endif*
>>>
>>> Indent is wrong.
>>
>> I missed that, thanks!
>>
>> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.01/
>>
>> Best regards,
>> Tobias
>>
>>>
>>> Otherwise this looks good.
>>>
>>> On May 2, 2014, at 2:15 AM, Tobias Hartmann
>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>>
>>>> Hi,
>>>>
>>>> please review the following patch for bug 8036851.
>>>>
>>>> *Problem*
>>>> Volatile double accesses are not treated different from normal
>>>> accesses in the C2 compiler with respect to atomicity because on x86
>>>> and sparc double accesses were always atomic. However, this may not
>>>> be case on other architectures. On an architecture where there are
>>>> atomic and non-atomic double accesses, we would have to implement all
>>>> accesses to be atomic, because the C2 compiler does not distinguish
>>>> between the two cases.
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
>>>>
>>>> *Solution*
>>>> The C2 structure is adapted to distinguish between volatile and
>>>> non-volatile double accesses.
>>>> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Eanoll/8036851/webrev.00/>
>>>>
>>>> *Tests*
>>>> JPRT
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>
>>
>>


From tobias.hartmann at oracle.com  Mon May  5 11:31:33 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 05 May 2014 13:31:33 +0200
Subject: [7] RFR(S): 8042250: Misleading command line output for
	ReservedCodeCacheSize validation
Message-ID: <53677695.7080702@oracle.com>

Hi Mattis,

bug [1] is fixed in JDK 8 and 9 by the fix for [2] but still occurs in 
JDK 7.

Please review and push the following small patch that fixes the bug in 
JDK 7.
Webrev: http://cr.openjdk.java.net/~anoll/8042250/webrev.00/

Thanks,
Tobias

[1] https://bugs.openjdk.java.net/browse/JDK-8042250
[2] https://bugs.openjdk.java.net/browse/JDK-8014972

From tobias.hartmann at oracle.com  Mon May  5 11:48:10 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 05 May 2014 13:48:10 +0200
Subject: [9] RFR(XS): 8042052: assert(t != NULL) failed: must set before
	get
In-Reply-To: <5363D683.4000007@oracle.com>
References: <536108FA.2070004@oracle.com>
	<536114CA.8070304@oracle.com>	<5363417D.5050609@oracle.com>
	<5363D683.4000007@oracle.com>
Message-ID: <53677A7A.2090600@oracle.com>

Thank you Vladimir.

Best,
Tobias

On 02.05.2014 19:31, Vladimir Kozlov wrote:
> This looks good.
>
> thanks,
> Vladimir
>
> On 5/1/14 11:55 PM, Tobias Hartmann wrote:
>> Hi Niclas,
>>
>> thanks for the feedback. Please see comments inline.
>>
>> On 04/30/2014 05:20 PM, Niclas Adlertz wrote:
>>> Hi Tobias,
>>>
>>> Thank you for catching this.
>>> I would say you can then change "_gvn.transform(result)" to just 
>>> "result" inside "inline_pow()", after the call to
>>> "finish_pow_exp()" at line 1931:
>>>
>>> From:
>>> // the result from finish_pow_exp is now input to the phi node
>>>
>>>
>>> phi_node->init_req(2, _gvn.transform(result));
>>>
>>> To:
>>> phi_node->init_req(2, result);
>>>
>>> since "result" has already been returned from "_gvn.transform()" 
>>> either inside "finish_pow_exp" or before the call,
>>> inside "inline_pow()".
>>
>> Done.
>>
>>>
>>> Also since "_gvn.transform()" possibly returns a new node, this:
>>> // Make sure type of PhiNode is recorded
>>> _gvn.transform(result_val);
>>> return result_val;
>>>
>>> should be replaced with:
>>> return _gvn.transform(result_val);
>>>
>>> (I don't think the comment is nescessary since we need to record 
>>> nodes at many other places as well)
>>
>> Yes, I missed that _gvn.transform(...) may return a new node. I 
>> changed the code according to your suggestions.
>>
>> New webrev: http://cr.openjdk.java.net/~anoll/8042052/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eanoll/8042052/webrev.01/>
>>
>> Thanks,
>> Tobias
>>
>>
>>>
>>> Kind Regards,
>>> Niclas Adlertz
>>>
>>> On 04/30/2014 04:30 PM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> please review the following patch for bug 8042052.
>>>>
>>>> *Problem*
>>>> The changes introduced by the fix for 8041912 [1] removed the call to
>>>> set_result(...) in LibraryCallKit::finish_pow_exp(...) that called
>>>> gvn.transform on the PhiNode results_val. The type of the PhiNode is
>>>> therefore not recorded in the gvn. The PhiNode is returned and later
>>>> accessed as an input to a StoreNode in
>>>> PhaseGVN::transform_no_reclaim(...). The call to StoreNode::Value 
>>>> tries
>>>> to look up the type of the PhiNode and triggers the assert in
>>>> PhaseTransform::type(...) because the type is not set.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042052
>>>>
>>>> *Solution*
>>>> A call to _gvn.transform is added to make sure the type of the PhiNode
>>>> is recorded.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~anoll/8042052/webrev.00/
>>>>
>>>> *Tests:*
>>>> Failing test (testMathExpDouble), JPRT
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8041912
>>>>
>>


From volker.simonis at gmail.com  Mon May  5 12:18:09 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 5 May 2014 14:18:09 +0200
Subject: RFR (S) JDK-8041620: Solaris Studio 12.4 C++ 5.13 change in
	behavior for placing friend declarations within surrounding scope
In-Reply-To: <5366A10A.7000109@oracle.com>
References: <53669162.9080500@oracle.com>
	<5366A10A.7000109@oracle.com>
Message-ID: <CA+3eh10u7NpSvy6b3F91-76aOLOc06=zVgLc4Pnrxw=k0sOEnw@mail.gmail.com>

On Sun, May 4, 2014 at 10:20 PM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Lois,
>
> Deletion of FileBuffRegion looks okay to me.
>
> Otherwise would the fix have been to change
>
> friend ostream& operator<< (ostream&, FileBuffRegion&);
>
> to
>
> friend ostream& ::std::operator<< (ostream&, FileBuffRegion&);
>

No, you would just have to declare:

class FileBuffRegion;
ostream& operator<< (ostream&, FileBuffRegion&);

class FileBuffRegion {
  ...
  friend ostream& operator<< (ostream&, FileBuffRegion&);
};

right before the definition of the class FileBuffRegion where the
operator is declared as a friend (as explained in
http://docs.oracle.com/cd/E37069_01/html/E37075/gnyjb.html#OSSCPgnyly).

The error just says that the compiler can not find a matching
operator<< declaration in the enclosing scope of class FileBuffRegion
and that the only operator<< declaration which it does find is not
compatible with the one used in the friend declaration.

Regards,
Volker

> ?
>
> Thanks,
> David
>
>
> On 5/05/2014 5:13 AM, Lois Foltan wrote:
>>
>> Hello,
>>
>> Please review the following fix:
>>
>> Webrev:
>>      http://cr.openjdk.java.net/~lfoltan/bug_jdk8041620/
>>
>> Bug: Solaris Studio 12.4 C++ 5.13 change in behavior for placing friend
>> declarations within surrounding scope
>>      https://bugs.openjdk.java.net/browse/JDK-8041620
>>
>> Summary:
>> Solaris Studio 12.4 C++ 5.13 compiler generates the following warning
>> level compilation diagnostic for
>> adlc/filebuff.hpp:
>>
>> "<directory>/src/share/vm/adlc/filebuff.hpp", line 107: Error:
>> Unqualified name '<<' in friend declaration is looked up in the nearest
>> enclosing namespace and does not refer to existing
>> '::std::operator<<<_charT, _Traits>(basic_ostream<_charT, _Traits>&,
>> _charT)'.
>> 1 Error(s) detected.
>>
>> C++ 5.13 external beta documentation at
>> http://docs.oracle.com/cd/E37069_01/html/E37075/gnyjb.html#OSSCPgnyly,
>> details this change in behavior for friend declarations.  Thank you to
>> Christian Thalinger for pointing out that
>> within filebuff.hpp, class FileBuffRegion is no longer used. Instead of
>> fixing the friend declaration in unused code,
>> removing FileBuffRegion.
>>
>> Tests:
>> JPRT build & test, Hotspot's JTREG test system, vm.quick.testlist

From david.simms at oracle.com  Mon May  5 11:37:40 2014
From: david.simms at oracle.com (David Simms)
Date: Mon, 05 May 2014 13:37:40 +0200
Subject: RFR (S) JDK-6311046: -Xcheck:jni should support checking of
	GetPrimitiveArrayCritical
Message-ID: <53677804.70700@oracle.com>

Gidday all:

Bug/Enhancement: https://bugs.openjdk.java.net/browse/JDK-6311046

Web review: http://cr.openjdk.java.net/~dsimms/6311046/rev2/

Cleaned up the "hand rolled" memory bounds checking in 
os::malloc/realloc/free and type checking in checked JNI (GetString*), 
and unified into a single helper class "FencedMemory". Added some extra 
checks to checked JNI (release mode).

There is now some extra debugging support for free/release operations, 
FencedMemory::release_for_freeing()" will now mark user bytes with 
"freeBlockPad", which did yeld a result when testing:

Found a minor bug in CompilerQueue (hence CC compiler ML), shouldn't be 
a problem in practice (probably won't crash), but the code is 
incorrect...and now fixed here.

Testing Completed:

Ran on all platforms:

  * JPRT
  * jteg jdk_core & jdk_svc
  * "RT nightly".


Cheers
/David Simms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140505/d06af2b6/attachment-0001.html>

From lois.foltan at oracle.com  Mon May  5 13:12:07 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 05 May 2014 09:12:07 -0400
Subject: RFR (XS) JDK-8041627: Solaris Studio 12.4 C++ 5.13 compilation
	error due to lack of "surplus" prototype for binaryTreeDictionary.cpp
In-Reply-To: <53669FA2.5040501@oracle.com>
References: <53668E76.9070601@oracle.com> <53669FA2.5040501@oracle.com>
Message-ID: <53678E27.6000308@oracle.com>

Thanks David for the review!
Lois

On 5/4/2014 4:14 PM, David Holmes wrote:
> Hi Lois,
>
> On 5/05/2014 5:01 AM, Lois Foltan wrote:
>> Hello,
>>
>> Please review the following fix:
>>
>> Webrev:
>>      http://cr.openjdk.java.net/~lfoltan/bug_jdk8041627
>>
>> Bug: Solaris Studio 12.4 C++ 5.13 compilation error due to lack of
>> "surplus" prototype for binaryTreeDictionary.cpp
>>      https://bugs.openjdk.java.net/browse/JDK-8041627
>>
>> Summary:
>> Thank you to Christian Thalinger for posting the code fix for this
>> issue.  Solaris Studio 12.4 C++ 5.13
>> generates the following compilation error diagnostic concerning the use
>> of "surplus" at line 123:
>> "<directory>/src/share/vm/memory/binaryTreeDictionary.cpp", line 123:
>> Error: The function "surplus" must have a prototype
>
> Curious error message (to me).
>
> Fix looks fine. Hopefully this is the last such change to be made to 
> this code.
>
> David
> -----
>
>> Tests:
>> JPRT build & test, Hotspot's JTREG test system, vm.quick.testlist


From lois.foltan at oracle.com  Mon May  5 13:15:26 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 05 May 2014 09:15:26 -0400
Subject: RFR (S) JDK-8041620: Solaris Studio 12.4 C++ 5.13 change in
	behavior for placing friend declarations within surrounding scope
In-Reply-To: <5366A10A.7000109@oracle.com>
References: <53669162.9080500@oracle.com> <5366A10A.7000109@oracle.com>
Message-ID: <53678EEE.1030405@oracle.com>


On 5/4/2014 4:20 PM, David Holmes wrote:
> Hi Lois,
>
> Deletion of FileBuffRegion looks okay to me.
>
> Otherwise would the fix have been to change
>
> friend ostream& operator<< (ostream&, FileBuffRegion&);
>
> to
>
> friend ostream& ::std::operator<< (ostream&, FileBuffRegion&);
>
> ?

Hi David,
Thanks for the review.  Volker Simonis' follow on email provides an 
example of how this would be fixed if the code was not being removed.  
The friend function would need to be declared in the outer scope prior 
to the class declaration.
Lois

>
> Thanks,
> David
>
> On 5/05/2014 5:13 AM, Lois Foltan wrote:
>> Hello,
>>
>> Please review the following fix:
>>
>> Webrev:
>>      http://cr.openjdk.java.net/~lfoltan/bug_jdk8041620/
>>
>> Bug: Solaris Studio 12.4 C++ 5.13 change in behavior for placing friend
>> declarations within surrounding scope
>>      https://bugs.openjdk.java.net/browse/JDK-8041620
>>
>> Summary:
>> Solaris Studio 12.4 C++ 5.13 compiler generates the following warning
>> level compilation diagnostic for
>> adlc/filebuff.hpp:
>>
>> "<directory>/src/share/vm/adlc/filebuff.hpp", line 107: Error:
>> Unqualified name '<<' in friend declaration is looked up in the nearest
>> enclosing namespace and does not refer to existing
>> '::std::operator<<<_charT, _Traits>(basic_ostream<_charT, _Traits>&,
>> _charT)'.
>> 1 Error(s) detected.
>>
>> C++ 5.13 external beta documentation at
>> http://docs.oracle.com/cd/E37069_01/html/E37075/gnyjb.html#OSSCPgnyly,
>> details this change in behavior for friend declarations.  Thank you to
>> Christian Thalinger for pointing out that
>> within filebuff.hpp, class FileBuffRegion is no longer used. Instead of
>> fixing the friend declaration in unused code,
>> removing FileBuffRegion.
>>
>> Tests:
>> JPRT build & test, Hotspot's JTREG test system, vm.quick.testlist


From lois.foltan at oracle.com  Mon May  5 13:17:22 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 05 May 2014 09:17:22 -0400
Subject: RFR (S) JDK-8041620: Solaris Studio 12.4 C++ 5.13 change in
	behavior for placing friend declarations within surrounding scope
In-Reply-To: <CA+3eh10u7NpSvy6b3F91-76aOLOc06=zVgLc4Pnrxw=k0sOEnw@mail.gmail.com>
References: <53669162.9080500@oracle.com> <5366A10A.7000109@oracle.com>
	<CA+3eh10u7NpSvy6b3F91-76aOLOc06=zVgLc4Pnrxw=k0sOEnw@mail.gmail.com>
Message-ID: <53678F62.6090106@oracle.com>

Yes, that looks correct, thanks Volker for the example.
Lois

On 5/5/2014 8:18 AM, Volker Simonis wrote:
> On Sun, May 4, 2014 at 10:20 PM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Lois,
>>
>> Deletion of FileBuffRegion looks okay to me.
>>
>> Otherwise would the fix have been to change
>>
>> friend ostream& operator<< (ostream&, FileBuffRegion&);
>>
>> to
>>
>> friend ostream& ::std::operator<< (ostream&, FileBuffRegion&);
>>
> No, you would just have to declare:
>
> class FileBuffRegion;
> ostream& operator<< (ostream&, FileBuffRegion&);
>
> class FileBuffRegion {
>    ...
>    friend ostream& operator<< (ostream&, FileBuffRegion&);
> };
>
> right before the definition of the class FileBuffRegion where the
> operator is declared as a friend (as explained in
> http://docs.oracle.com/cd/E37069_01/html/E37075/gnyjb.html#OSSCPgnyly).
>
> The error just says that the compiler can not find a matching
> operator<< declaration in the enclosing scope of class FileBuffRegion
> and that the only operator<< declaration which it does find is not
> compatible with the one used in the friend declaration.
>
> Regards,
> Volker
>
>> ?
>>
>> Thanks,
>> David
>>
>>
>> On 5/05/2014 5:13 AM, Lois Foltan wrote:
>>> Hello,
>>>
>>> Please review the following fix:
>>>
>>> Webrev:
>>>       http://cr.openjdk.java.net/~lfoltan/bug_jdk8041620/
>>>
>>> Bug: Solaris Studio 12.4 C++ 5.13 change in behavior for placing friend
>>> declarations within surrounding scope
>>>       https://bugs.openjdk.java.net/browse/JDK-8041620
>>>
>>> Summary:
>>> Solaris Studio 12.4 C++ 5.13 compiler generates the following warning
>>> level compilation diagnostic for
>>> adlc/filebuff.hpp:
>>>
>>> "<directory>/src/share/vm/adlc/filebuff.hpp", line 107: Error:
>>> Unqualified name '<<' in friend declaration is looked up in the nearest
>>> enclosing namespace and does not refer to existing
>>> '::std::operator<<<_charT, _Traits>(basic_ostream<_charT, _Traits>&,
>>> _charT)'.
>>> 1 Error(s) detected.
>>>
>>> C++ 5.13 external beta documentation at
>>> http://docs.oracle.com/cd/E37069_01/html/E37075/gnyjb.html#OSSCPgnyly,
>>> details this change in behavior for friend declarations.  Thank you to
>>> Christian Thalinger for pointing out that
>>> within filebuff.hpp, class FileBuffRegion is no longer used. Instead of
>>> fixing the friend declaration in unused code,
>>> removing FileBuffRegion.
>>>
>>> Tests:
>>> JPRT build & test, Hotspot's JTREG test system, vm.quick.testlist


From paul.sandoz at oracle.com  Mon May  5 15:02:00 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 5 May 2014 17:02:00 +0200
Subject: Request for Reviews (S): JDK-8003585 strength reduce or eliminate
	range checks for power-of-two sized arrays
In-Reply-To: <530209A8.1020501@oracle.com>
References: <CA+cQ+tR5c3y3uLpdO2Gop-RA0ZPJ4Mmq9yAAK5dOpFtgv-XPcg@mail.gmail.com>	<440F2280-4B25-4AE6-A4F6-DDD4EB529636@oracle.com>	<52FC129D.7040409@oracle.com>	<CA+cQ+tTzA822citeYM0zCNE3FDyBk9hTO2h2i6POiJWSar6hVA@mail.gmail.com>	<CA+cQ+tTWkkJHwcvJ4R=f31ve9vRwG5TfizHfo56sO9R3p3sRcQ@mail.gmail.com>	<52FE6A08.20400@oracle.com>
	<CA+cQ+tQ00O1bT0JAAX9Lk+hPrfLV0PgQoiO1wmEUbKrPrqi1kA@mail.gmail.com>
	<52FE7313.3060404@oracle.com> <530209A8.1020501@oracle.com>
Message-ID: <DC638183-2429-4FD2-B455-F87C0FD7EBFE@oracle.com>

Hi Nils,

Any update on this?

I have been looking at this area in the context of array access for JEP 193: Enhanced Volatiles (i will send another email on that later today). But I was wanted to share some initial perf results with this patch.

Here are the relevant snippets of benchmark code:

    private static final int N = 1 << Integer.getInteger("N", 8);
    private static final int START = (N >> 1);
    private static final int END = (N >> 1) + N;
...

    private Value value;

    private Value[] receiver;

    @Setup
    public void setUp() throws Exception {
        value = new ExtendedValue(1);
        receiver = new ExtendedValue[N];
        for (int i = 0; i < receiver.length; i++) {
            receiver[i] = value;
        }
    }
...
    @GenerateMicroBenchmark
    public int relaxed_r_aa() {
        Value[] _receiver = receiver;
        int sum = 0;
        for (int i = START; i < END; i++) {
            int j = i & (_receiver.length - 1);
            sum += _receiver[j].i;
        }
        return sum;
    }

    @GenerateMicroBenchmark
    public Value[] relaxed_w_aa() {
        Value[] _receiver = receiver;
        for (int i = START; i < END; i++) {
            int j = i & (_receiver.length - 1);
            _receiver[j] = value;
        }
        return _receiver;
    }

    @GenerateMicroBenchmark
    public int relaxed_r_unsafe() {
        Value[] _receiver = receiver;
        int sum = 0;
        for (int i = START; i < END; i++) {
            int j = i & (_receiver.length - 1);
            Value v = (Value) UNSAFE.getObject(
                    _receiver,
                    (((long) j) << UNSAFE_ARRAY_SHIFT_V) + UNSAFE_ARRAY_OFFSET_V);
            sum += v.i;
        }
        return sum;
    }

    @GenerateMicroBenchmark
    public Value[] relaxed_w_unsafe() {
        Value[] _receiver = receiver;
        for (int i = START; i < END; i++) {
            int j = i & (_receiver.length - 1);
            UNSAFE.putObject(_receiver,
                             (((long) j) << UNSAFE_ARRAY_SHIFT_V) + UNSAFE_ARRAY_OFFSET_V,
                             value);
        }
        return _receiver;
    }

Here are some results on OpenJDK 9 without the patch (times are in ns/op for N=1,8,64,512, for one thread, measured on a Dell laptop with an Intel Core i5-2520 CPU @ 2.50GHz):

    Benchmark                             1        8        64        512
    relaxed_r_aa                        1.304    9.128    48.599    372.214
    relaxed_r_unsafe                    1.152    6.615    44.456    348.989

    relaxed_w_aa                        3.256   16.105    76.896    599.830
    relaxed_w_unsafe                    2.888   11.553    56.037    532.179

Here are the results with the patch applied to hotspot (in the dev repo):

    Benchmark                             1        8        64        512
    relaxed_r_aa                        1.291    6.664    37.604    285.830
    relaxed_r_unsafe                    1.151    6.621    44.483    348.249

    relaxed_w_aa                        3.279   12.646    66.324    481.281
    relaxed_w_unsafe                    2.888   11.549    56.028    531.589


One has to be a little careful interpreting the results since compilation of the JMH loop measurement method can monkey around with 'em (I think from OSR'ed to complete, which might be affecting how loops are unrolled, but i would need to dive into the machine code of the compiled methods to verify). However, even so this patch looks promising.

Paul.

On Feb 17, 2014, at 2:07 PM, Nils Eliasson <nils.eliasson at oracle.com> wrote:

> Current change passes JPRT. Running bigapps and nightly code policy as well.
> 
> Will wait for tests and reviewer go-ahead before pushing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140505/4d55d395/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140505/4d55d395/signature.asc>

From paul.sandoz at oracle.com  Mon May  5 15:20:36 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 5 May 2014 17:20:36 +0200
Subject: Unsafe for array access
Message-ID: <12C1134A-D491-4A59-ACF4-F6E2C10DA112@oracle.com>

Hi,

As part of some investigatory work for JEP 193: Enhanced Volatiles i have been looking at how enhanced (and safe) access to array elements could be implemented.

The obvious and simple choice is to reach for unsafe with a few safety checks, for example:

    @ForceInline
    static void setVolatile(ArrayRefHandle handle, Object[] array, int index,
            Object value) {
        if (index < 0 || index >= array.length) // bounds and null check
            throw new ArrayIndexOutOfBoundsException();
        UNSAFE.putObjectVolatile(array,
                                 (((long) index) << handle.ashift) + handle.abase,
                                 castReference(handle.componentType, value));
    }

The problem is the compiler does fully recognize an array access is going on and so certain optimizations tend not to kick in, such as removing or strength reducing bounds checks, or treating "index" as a signed value rather than unsigned.

Any clues/pointers on how i can hack things so that hotspot knows that an array access is going on in the above code, and views it as almost equivalent to following in terms of optimizations?

    @ForceInline
    static void setVolatile(ArrayRefHandle handle, Object[] array, int index,
            Object value) {
        if (index < 0 || index >= array.length) // bounds and null check
            throw new ArrayIndexOutOfBoundsException();
        array[i] = castReference(handle.componentType, value);
    }


Some context: ForkJoinPool is peppered with code like the following:

                            int i = (((a.length - 1) & b) << ASHIFT) + ABASE;
                            ForkJoinTask<?> t =
                                (ForkJoinTask<?>)U.getObjectVolatile(a, i);

Any viable replacement for direct Unsafe usages in that code will want those strength reducing optimizations to kick in.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140505/22512f76/signature-0001.asc>

From mattis.castegren at oracle.com  Mon May  5 15:20:17 2014
From: mattis.castegren at oracle.com (Mattis Castegren)
Date: Mon, 5 May 2014 08:20:17 -0700 (PDT)
Subject: [7] RFR(S): 8042250: Misleading command line output for
	ReservedCodeCacheSize validation
In-Reply-To: <53677695.7080702@oracle.com>
References: <53677695.7080702@oracle.com>
Message-ID: <980cc9cf-6a17-4093-985a-0c57855f24b4@default>

Hi

I'm not a committer. Forwarding this to Kevin. Kevin, could you look at this and push it?

We will also need a code review from an official reviewer. The fix is VERY small, as it only changes one line of output. Anyone who could review it right away?

Kind Regards
/Mattis

-----Original Message-----
From: Tobias Hartmann 
Sent: den 5 maj 2014 13:32
To: Mattis Castegren; Vladimir Kozlov
Cc: hotspot compiler
Subject: [7] RFR(S): 8042250: Misleading command line output for ReservedCodeCacheSize validation

Hi Mattis,

bug [1] is fixed in JDK 8 and 9 by the fix for [2] but still occurs in 
JDK 7.

Please review and push the following small patch that fixes the bug in 
JDK 7.
Webrev: http://cr.openjdk.java.net/~anoll/8042250/webrev.00/

Thanks,
Tobias

[1] https://bugs.openjdk.java.net/browse/JDK-8042250
[2] https://bugs.openjdk.java.net/browse/JDK-8014972

From vladimir.kozlov at oracle.com  Mon May  5 16:37:04 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 05 May 2014 09:37:04 -0700
Subject: [7] RFR(S): 8042250: Misleading command line output for
	ReservedCodeCacheSize validation
In-Reply-To: <980cc9cf-6a17-4093-985a-0c57855f24b4@default>
References: <53677695.7080702@oracle.com>
	<980cc9cf-6a17-4093-985a-0c57855f24b4@default>
Message-ID: <5367BE30.3050205@oracle.com>

You can count me as Reviewer for this fix.

Thanks,
Vladimir K

On 5/5/14 8:20 AM, Mattis Castegren wrote:
> Hi
>
> I'm not a committer. Forwarding this to Kevin. Kevin, could you look at this and push it?
>
> We will also need a code review from an official reviewer. The fix is VERY small, as it only changes one line of output. Anyone who could review it right away?
>
> Kind Regards
> /Mattis
>
> -----Original Message-----
> From: Tobias Hartmann
> Sent: den 5 maj 2014 13:32
> To: Mattis Castegren; Vladimir Kozlov
> Cc: hotspot compiler
> Subject: [7] RFR(S): 8042250: Misleading command line output for ReservedCodeCacheSize validation
>
> Hi Mattis,
>
> bug [1] is fixed in JDK 8 and 9 by the fix for [2] but still occurs in
> JDK 7.
>
> Please review and push the following small patch that fixes the bug in
> JDK 7.
> Webrev: http://cr.openjdk.java.net/~anoll/8042250/webrev.00/
>
> Thanks,
> Tobias
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8042250
> [2] https://bugs.openjdk.java.net/browse/JDK-8014972
>

From rednaxelafx at gmail.com  Mon May  5 19:10:33 2014
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Mon, 5 May 2014 12:10:33 -0700
Subject: Request for Reviews (S): JDK-8003585 strength reduce or eliminate
	range checks for power-of-two sized arrays
In-Reply-To: <DC638183-2429-4FD2-B455-F87C0FD7EBFE@oracle.com>
References: <CA+cQ+tR5c3y3uLpdO2Gop-RA0ZPJ4Mmq9yAAK5dOpFtgv-XPcg@mail.gmail.com>
	<440F2280-4B25-4AE6-A4F6-DDD4EB529636@oracle.com>
	<52FC129D.7040409@oracle.com>
	<CA+cQ+tTzA822citeYM0zCNE3FDyBk9hTO2h2i6POiJWSar6hVA@mail.gmail.com>
	<CA+cQ+tTWkkJHwcvJ4R=f31ve9vRwG5TfizHfo56sO9R3p3sRcQ@mail.gmail.com>
	<52FE6A08.20400@oracle.com>
	<CA+cQ+tQ00O1bT0JAAX9Lk+hPrfLV0PgQoiO1wmEUbKrPrqi1kA@mail.gmail.com>
	<52FE7313.3060404@oracle.com> <530209A8.1020501@oracle.com>
	<DC638183-2429-4FD2-B455-F87C0FD7EBFE@oracle.com>
Message-ID: <CA+cQ+tQ2FoMhSj_B-Q=zgv3sGtJo9HojhWDsEWkx-UThc+mqEA@mail.gmail.com>

Hi Paul,

Oops, my bad. I've been busy with my day work and hadn't got around to
write a test case for this patch, that's what caused the delay. I can try
to come up with a test case later this week if you can wait.

Best regards,
Kris


On Mon, May 5, 2014 at 8:02 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Nils,
>
> Any update on this?
>
> I have been looking at this area in the context of array access for JEP
> 193: Enhanced Volatiles (i will send another email on that later today).
> But I was wanted to share some initial perf results with this patch.
>
> Here are the relevant snippets of benchmark code:
>
>     private static final int N = 1 << Integer.getInteger("N", 8);
>     private static final int START = (N >> 1);
>     private static final int END = (N >> 1) + N;
> ...
>
>     private Value value;
>
>     private Value[] receiver;
>
>     @Setup
>     public void setUp() throws Exception {
>         value = new ExtendedValue(1);
>         receiver = new ExtendedValue[N];
>         for (int i = 0; i < receiver.length; i++) {
>             receiver[i] = value;
>         }
>     }
> ...
>     @GenerateMicroBenchmark
>     public int relaxed_r_aa() {
>         Value[] _receiver = receiver;
>         int sum = 0;
>         for (int i = START; i < END; i++) {
>             int j = i & (_receiver.length - 1);
>             sum += _receiver[j].i;
>         }
>         return sum;
>     }
>
>     @GenerateMicroBenchmark
>     public Value[] relaxed_w_aa() {
>         Value[] _receiver = receiver;
>         for (int i = START; i < END; i++) {
>             int j = i & (_receiver.length - 1);
>             _receiver[j] = value;
>         }
>         return _receiver;
>     }
>
>     @GenerateMicroBenchmark
>     public int relaxed_r_unsafe() {
>         Value[] _receiver = receiver;
>         int sum = 0;
>         for (int i = START; i < END; i++) {
>             int j = i & (_receiver.length - 1);
>             Value v = (Value) UNSAFE.getObject(
>                     _receiver,
>                     (((long) j) << UNSAFE_ARRAY_SHIFT_V) +
> UNSAFE_ARRAY_OFFSET_V);
>             sum += v.i;
>         }
>         return sum;
>     }
>
>     @GenerateMicroBenchmark
>     public Value[] relaxed_w_unsafe() {
>         Value[] _receiver = receiver;
>         for (int i = START; i < END; i++) {
>             int j = i & (_receiver.length - 1);
>             UNSAFE.putObject(_receiver,
>                              (((long) j) << UNSAFE_ARRAY_SHIFT_V) +
> UNSAFE_ARRAY_OFFSET_V,
>                              value);
>         }
>         return _receiver;
>     }
>
> Here are some results on OpenJDK 9 without the patch (times are in ns/op
> for N=1,8,64,512, for one thread, measured on a Dell laptop with an Intel
> Core i5-2520 CPU @ 2.50GHz):
>
>     Benchmark                             1        8        64        512
>     relaxed_r_aa                        1.304    9.128    48.599    372.214
>     relaxed_r_unsafe                    1.152    6.615    44.456    348.989
>
>     relaxed_w_aa                        3.256   16.105    76.896    599.830
>     relaxed_w_unsafe                    2.888   11.553    56.037    532.179
>
> Here are the results with the patch applied to hotspot (in the dev repo):
>
>     Benchmark                             1        8        64        512
>     relaxed_r_aa                        1.291    6.664    37.604    285.830
>     relaxed_r_unsafe                    1.151    6.621    44.483    348.249
>
>     relaxed_w_aa                        3.279   12.646    66.324    481.281
>     relaxed_w_unsafe                    2.888   11.549    56.028    531.589
>
>
> One has to be a little careful interpreting the results since compilation
> of the JMH loop measurement method can monkey around with 'em (I think from
> OSR'ed to complete, which might be affecting how loops are unrolled, but i
> would need to dive into the machine code of the compiled methods to
> verify). However, even so this patch looks promising.
>
> Paul.
>
> On Feb 17, 2014, at 2:07 PM, Nils Eliasson <nils.eliasson at oracle.com>
> wrote:
>
> Current change passes JPRT. Running bigapps and nightly code policy as
> well.
>
> Will wait for tests and reviewer go-ahead before pushing.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140505/a47552c8/attachment.html>

From vladimir.kozlov at oracle.com  Mon May  5 19:22:41 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 05 May 2014 12:22:41 -0700
Subject: RFR (S) JDK-8041620: Solaris Studio 12.4 C++ 5.13 change in
	behavior for placing friend declarations within surrounding scope
In-Reply-To: <53669162.9080500@oracle.com>
References: <53669162.9080500@oracle.com>
Message-ID: <5367E501.9020007@oracle.com>

Looks good.

Vladimir

On 5/4/14 12:13 PM, Lois Foltan wrote:
> Hello,
>
> Please review the following fix:
>
> Webrev:
>      http://cr.openjdk.java.net/~lfoltan/bug_jdk8041620/
>
> Bug: Solaris Studio 12.4 C++ 5.13 change in behavior for placing friend
> declarations within surrounding scope
>      https://bugs.openjdk.java.net/browse/JDK-8041620
>
> Summary:
> Solaris Studio 12.4 C++ 5.13 compiler generates the following warning
> level compilation diagnostic for
> adlc/filebuff.hpp:
>
> "<directory>/src/share/vm/adlc/filebuff.hpp", line 107: Error:
> Unqualified name '<<' in friend declaration is looked up in the nearest
> enclosing namespace and does not refer to existing
> '::std::operator<<<_charT, _Traits>(basic_ostream<_charT, _Traits>&,
> _charT)'.
> 1 Error(s) detected.
>
> C++ 5.13 external beta documentation at
> http://docs.oracle.com/cd/E37069_01/html/E37075/gnyjb.html#OSSCPgnyly,
> details this change in behavior for friend declarations.  Thank you to
> Christian Thalinger for pointing out that
> within filebuff.hpp, class FileBuffRegion is no longer used. Instead of
> fixing the friend declaration in unused code,
> removing FileBuffRegion.
>
> Tests:
> JPRT build & test, Hotspot's JTREG test system, vm.quick.testlist

From vladimir.kozlov at oracle.com  Mon May  5 20:36:42 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 05 May 2014 13:36:42 -0700
Subject: RFR(XS) 8041415: remove port.{cpp,hpp} files
In-Reply-To: <5367F2D5.4080606@oracle.com>
References: <5367F2D5.4080606@oracle.com>
Message-ID: <5367F65A.6090906@oracle.com>

CC to compiler alias since you changing our code.

Copyright year change should be 2014.

FileBuffRegion removal is done under separate bug 8041620 by Lois 
Foltan, the review was sent today today.

domgraph.cpp, output.cpp: use max_juint instead of (uint) -1.

Thanks,
Vladimir

On 5/5/14 1:21 PM, Zhengyu Gu wrote:
> This is a code cleanup based on attached patch from Christian Thalinger.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8041415
> Webrev:

  http://cr.openjdk.java.net/~zgu/8041415/webrev.00/

>
> Test:
>    JPRT
>
> Thanks,
>

From vladimir.kozlov at oracle.com  Mon May  5 20:56:35 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 05 May 2014 13:56:35 -0700
Subject: RFR (S) JDK-6311046: -Xcheck:jni should support checking of
	GetPrimitiveArrayCritical
In-Reply-To: <53677804.70700@oracle.com>
References: <53677804.70700@oracle.com>
Message-ID: <5367FB03.7000302@oracle.com>

Hi David,

compileBroker.cpp was recently modified by 8040798 (it was pushed into 
main repo today):

http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/48c15b47a4f1

And it still has the problem you pointed (overwrite _next pointer). I 
think it should be a separate fix since we don't delete the task object 
now but put it on free list. I will file a bug. Please, remove this 
change from yours.

Thanks,
Vladimir

On 5/5/14 4:37 AM, David Simms wrote:
> Gidday all:
>
> Bug/Enhancement: https://bugs.openjdk.java.net/browse/JDK-6311046
>
> Web review: http://cr.openjdk.java.net/~dsimms/6311046/rev2/
>
> Cleaned up the "hand rolled" memory bounds checking in
> os::malloc/realloc/free and type checking in checked JNI (GetString*),
> and unified into a single helper class "FencedMemory". Added some extra
> checks to checked JNI (release mode).
>
> There is now some extra debugging support for free/release operations,
> FencedMemory::release_for_freeing()" will now mark user bytes with
> "freeBlockPad", which did yeld a result when testing:
>
> Found a minor bug in CompilerQueue (hence CC compiler ML), shouldn't be
> a problem in practice (probably won't crash), but the code is
> incorrect...and now fixed here.
>
> Testing Completed:
>
> Ran on all platforms:
>
>   * JPRT
>   * jteg jdk_core & jdk_svc
>   * "RT nightly".
>
>
> Cheers
> /David Simms

From lois.foltan at oracle.com  Mon May  5 21:12:52 2014
From: lois.foltan at oracle.com (Lois Foltan)
Date: Mon, 05 May 2014 17:12:52 -0400
Subject: RFR (S) JDK-8041620: Solaris Studio 12.4 C++ 5.13 change in
	behavior for placing friend declarations within surrounding scope
In-Reply-To: <5367E501.9020007@oracle.com>
References: <53669162.9080500@oracle.com> <5367E501.9020007@oracle.com>
Message-ID: <5367FED4.4020301@oracle.com>

Thank you Vladimir!
Lois

On 5/5/2014 3:22 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Vladimir
>
> On 5/4/14 12:13 PM, Lois Foltan wrote:
>> Hello,
>>
>> Please review the following fix:
>>
>> Webrev:
>>      http://cr.openjdk.java.net/~lfoltan/bug_jdk8041620/
>>
>> Bug: Solaris Studio 12.4 C++ 5.13 change in behavior for placing friend
>> declarations within surrounding scope
>>      https://bugs.openjdk.java.net/browse/JDK-8041620
>>
>> Summary:
>> Solaris Studio 12.4 C++ 5.13 compiler generates the following warning
>> level compilation diagnostic for
>> adlc/filebuff.hpp:
>>
>> "<directory>/src/share/vm/adlc/filebuff.hpp", line 107: Error:
>> Unqualified name '<<' in friend declaration is looked up in the nearest
>> enclosing namespace and does not refer to existing
>> '::std::operator<<<_charT, _Traits>(basic_ostream<_charT, _Traits>&,
>> _charT)'.
>> 1 Error(s) detected.
>>
>> C++ 5.13 external beta documentation at
>> http://docs.oracle.com/cd/E37069_01/html/E37075/gnyjb.html#OSSCPgnyly,
>> details this change in behavior for friend declarations.  Thank you to
>> Christian Thalinger for pointing out that
>> within filebuff.hpp, class FileBuffRegion is no longer used. Instead of
>> fixing the friend declaration in unused code,
>> removing FileBuffRegion.
>>
>> Tests:
>> JPRT build & test, Hotspot's JTREG test system, vm.quick.testlist


From christian.thalinger at oracle.com  Tue May  6 00:26:48 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 5 May 2014 14:26:48 -1000
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <53676DED.4030807@oracle.com>
References: <53638C6B.10600@oracle.com>	<212507C6-507A-4813-B796-42413A5D9A14@oracle.com>
	<53673794.20809@oracle.com> <53674C50.4010008@oracle.com>
	<53676DED.4030807@oracle.com>
Message-ID: <71396864-167A-4996-9146-7F8E7769C73F@oracle.com>

Looks good.

On May 5, 2014, at 12:54 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi Niclas,
> 
> thanks for the feedback.
> 
> On 05.05.2014 10:31, Niclas Adlertz wrote:
>> Minor thing:
>> bool require_atomic_access()       { return _require_atomic_access; }
>> could be defined as:
>> bool require_atomic_access() const { return _require_atomic_access; }
>> 
>> You could also change that for LoadL/StoreL while you are at it :)
> 
> Done.
> 
> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.02/
> 
> Thanks,
> Tobias
> 
>> 
>> Kind Regards,
>> Niclas Adlertz
>> 
>> On 05/05/2014 09:02 AM, Tobias Hartmann wrote:
>>> Hi Christian,
>>> 
>>> thanks for the review.
>>> 
>>> On 05/02/2014 09:23 PM, Christian Thalinger wrote:
>>>> *src/share/vm/opto/memnode.hpp:*
>>>> *
>>>> *
>>>> *+   #ifndef PRODUCT*
>>>> *+     virtual void dump_spec(outputStream *st) const {*
>>>> *+       LoadNode::dump_spec(st);*
>>>> *+       if (_require_atomic_access)  st->print(" Atomic!");*
>>>> *+     }*
>>>> *+   #endif*
>>>> 
>>>> Indent is wrong.
>>> 
>>> I missed that, thanks!
>>> 
>>> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.01/
>>> 
>>> Best regards,
>>> Tobias
>>> 
>>>> 
>>>> Otherwise this looks good.
>>>> 
>>>> On May 2, 2014, at 2:15 AM, Tobias Hartmann
>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> please review the following patch for bug 8036851.
>>>>> 
>>>>> *Problem*
>>>>> Volatile double accesses are not treated different from normal
>>>>> accesses in the C2 compiler with respect to atomicity because on x86
>>>>> and sparc double accesses were always atomic. However, this may not
>>>>> be case on other architectures. On an architecture where there are
>>>>> atomic and non-atomic double accesses, we would have to implement all
>>>>> accesses to be atomic, because the C2 compiler does not distinguish
>>>>> between the two cases.
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
>>>>> 
>>>>> *Solution*
>>>>> The C2 structure is adapted to distinguish between volatile and
>>>>> non-volatile double accesses.
>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/
>>>>> <http://cr.openjdk.java.net/%7Eanoll/8036851/webrev.00/>
>>>>> 
>>>>> *Tests*
>>>>> JPRT
>>>>> 
>>>>> Thanks,
>>>>> Tobias
>>>>> 
>>>> 
>>> 
>>> 
> 


From igor.veresov at oracle.com  Tue May  6 02:44:41 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Mon, 5 May 2014 19:44:41 -0700
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with DeoptimizeALot
Message-ID: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>

The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows:

1. Initially a method is compiled as usual (no instrumentation, no overhead).
2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code.
3. If we ever request to compile this method again the aging code is inserted, which decrements the counter.
4. The value of the counter is then used by the sweeper to determine is the method is in fact used.
5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again. 

Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/

Testing: 
- jprt,
- aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations.

igor

From tobias.hartmann at oracle.com  Tue May  6 06:29:16 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 06 May 2014 08:29:16 +0200
Subject: [7] RFR(S): 8042250: Misleading command line output for
	ReservedCodeCacheSize validation
In-Reply-To: <5367BE30.3050205@oracle.com>
References: <53677695.7080702@oracle.com>
	<980cc9cf-6a17-4093-985a-0c57855f24b4@default>
	<5367BE30.3050205@oracle.com>
Message-ID: <5368813C.1090608@oracle.com>

Hi,

Mattis, Vladimir, thanks for the feedback.

Best,
Tobias

On 05.05.2014 18:37, Vladimir Kozlov wrote:
> You can count me as Reviewer for this fix.
>
> Thanks,
> Vladimir K
>
> On 5/5/14 8:20 AM, Mattis Castegren wrote:
>> Hi
>>
>> I'm not a committer. Forwarding this to Kevin. Kevin, could you look 
>> at this and push it?
>>
>> We will also need a code review from an official reviewer. The fix is 
>> VERY small, as it only changes one line of output. Anyone who could 
>> review it right away?
>>
>> Kind Regards
>> /Mattis
>>
>> -----Original Message-----
>> From: Tobias Hartmann
>> Sent: den 5 maj 2014 13:32
>> To: Mattis Castegren; Vladimir Kozlov
>> Cc: hotspot compiler
>> Subject: [7] RFR(S): 8042250: Misleading command line output for 
>> ReservedCodeCacheSize validation
>>
>> Hi Mattis,
>>
>> bug [1] is fixed in JDK 8 and 9 by the fix for [2] but still occurs in
>> JDK 7.
>>
>> Please review and push the following small patch that fixes the bug in
>> JDK 7.
>> Webrev: http://cr.openjdk.java.net/~anoll/8042250/webrev.00/
>>
>> Thanks,
>> Tobias
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8042250
>> [2] https://bugs.openjdk.java.net/browse/JDK-8014972
>>


From tobias.hartmann at oracle.com  Tue May  6 06:54:06 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 06 May 2014 08:54:06 +0200
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <71396864-167A-4996-9146-7F8E7769C73F@oracle.com>
References: <53638C6B.10600@oracle.com>	<212507C6-507A-4813-B796-42413A5D9A14@oracle.com>
	<53673794.20809@oracle.com> <53674C50.4010008@oracle.com>
	<53676DED.4030807@oracle.com>
	<71396864-167A-4996-9146-7F8E7769C73F@oracle.com>
Message-ID: <5368870E.4080901@oracle.com>

Hi Chris,

thanks for the review. Do I need a second one?

Best,
Tobias

On 06.05.2014 02:26, Christian Thalinger wrote:
> Looks good.
>
> On May 5, 2014, at 12:54 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>
>> Hi Niclas,
>>
>> thanks for the feedback.
>>
>> On 05.05.2014 10:31, Niclas Adlertz wrote:
>>> Minor thing:
>>> bool require_atomic_access()       { return _require_atomic_access; }
>>> could be defined as:
>>> bool require_atomic_access() const { return _require_atomic_access; }
>>>
>>> You could also change that for LoadL/StoreL while you are at it :)
>> Done.
>>
>> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.02/
>>
>> Thanks,
>> Tobias
>>
>>> Kind Regards,
>>> Niclas Adlertz
>>>
>>> On 05/05/2014 09:02 AM, Tobias Hartmann wrote:
>>>> Hi Christian,
>>>>
>>>> thanks for the review.
>>>>
>>>> On 05/02/2014 09:23 PM, Christian Thalinger wrote:
>>>>> *src/share/vm/opto/memnode.hpp:*
>>>>> *
>>>>> *
>>>>> *+   #ifndef PRODUCT*
>>>>> *+     virtual void dump_spec(outputStream *st) const {*
>>>>> *+       LoadNode::dump_spec(st);*
>>>>> *+       if (_require_atomic_access)  st->print(" Atomic!");*
>>>>> *+     }*
>>>>> *+   #endif*
>>>>>
>>>>> Indent is wrong.
>>>> I missed that, thanks!
>>>>
>>>> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.01/
>>>>
>>>> Best regards,
>>>> Tobias
>>>>
>>>>> Otherwise this looks good.
>>>>>
>>>>> On May 2, 2014, at 2:15 AM, Tobias Hartmann
>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> please review the following patch for bug 8036851.
>>>>>>
>>>>>> *Problem*
>>>>>> Volatile double accesses are not treated different from normal
>>>>>> accesses in the C2 compiler with respect to atomicity because on x86
>>>>>> and sparc double accesses were always atomic. However, this may not
>>>>>> be case on other architectures. On an architecture where there are
>>>>>> atomic and non-atomic double accesses, we would have to implement all
>>>>>> accesses to be atomic, because the C2 compiler does not distinguish
>>>>>> between the two cases.
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
>>>>>>
>>>>>> *Solution*
>>>>>> The C2 structure is adapted to distinguish between volatile and
>>>>>> non-volatile double accesses.
>>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Eanoll/8036851/webrev.00/>
>>>>>>
>>>>>> *Tests*
>>>>>> JPRT
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>


From niclas.adlertz at oracle.com  Tue May  6 06:58:08 2014
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Tue, 06 May 2014 08:58:08 +0200
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <5368870E.4080901@oracle.com>
References: <53638C6B.10600@oracle.com>	<212507C6-507A-4813-B796-42413A5D9A14@oracle.com>
	<53673794.20809@oracle.com> <53674C50.4010008@oracle.com>
	<53676DED.4030807@oracle.com>
	<71396864-167A-4996-9146-7F8E7769C73F@oracle.com>
	<5368870E.4080901@oracle.com>
Message-ID: <53688800.1070403@oracle.com>

Looks good to me as well.

Kind Regards,
Niclas Adlertz

On 05/06/2014 08:54 AM, Tobias Hartmann wrote:
> Hi Chris,
>
> thanks for the review. Do I need a second one?
>
> Best,
> Tobias
>
> On 06.05.2014 02:26, Christian Thalinger wrote:
>> Looks good.
>>
>> On May 5, 2014, at 12:54 AM, Tobias Hartmann
>> <tobias.hartmann at oracle.com> wrote:
>>
>>> Hi Niclas,
>>>
>>> thanks for the feedback.
>>>
>>> On 05.05.2014 10:31, Niclas Adlertz wrote:
>>>> Minor thing:
>>>> bool require_atomic_access()       { return _require_atomic_access; }
>>>> could be defined as:
>>>> bool require_atomic_access() const { return _require_atomic_access; }
>>>>
>>>> You could also change that for LoadL/StoreL while you are at it :)
>>> Done.
>>>
>>> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.02/
>>>
>>> Thanks,
>>> Tobias
>>>
>>>> Kind Regards,
>>>> Niclas Adlertz
>>>>
>>>> On 05/05/2014 09:02 AM, Tobias Hartmann wrote:
>>>>> Hi Christian,
>>>>>
>>>>> thanks for the review.
>>>>>
>>>>> On 05/02/2014 09:23 PM, Christian Thalinger wrote:
>>>>>> *src/share/vm/opto/memnode.hpp:*
>>>>>> *
>>>>>> *
>>>>>> *+   #ifndef PRODUCT*
>>>>>> *+     virtual void dump_spec(outputStream *st) const {*
>>>>>> *+       LoadNode::dump_spec(st);*
>>>>>> *+       if (_require_atomic_access)  st->print(" Atomic!");*
>>>>>> *+     }*
>>>>>> *+   #endif*
>>>>>>
>>>>>> Indent is wrong.
>>>>> I missed that, thanks!
>>>>>
>>>>> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.01/
>>>>>
>>>>> Best regards,
>>>>> Tobias
>>>>>
>>>>>> Otherwise this looks good.
>>>>>>
>>>>>> On May 2, 2014, at 2:15 AM, Tobias Hartmann
>>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> please review the following patch for bug 8036851.
>>>>>>>
>>>>>>> *Problem*
>>>>>>> Volatile double accesses are not treated different from normal
>>>>>>> accesses in the C2 compiler with respect to atomicity because on x86
>>>>>>> and sparc double accesses were always atomic. However, this may not
>>>>>>> be case on other architectures. On an architecture where there are
>>>>>>> atomic and non-atomic double accesses, we would have to implement
>>>>>>> all
>>>>>>> accesses to be atomic, because the C2 compiler does not distinguish
>>>>>>> between the two cases.
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
>>>>>>>
>>>>>>> *Solution*
>>>>>>> The C2 structure is adapted to distinguish between volatile and
>>>>>>> non-volatile double accesses.
>>>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/
>>>>>>> <http://cr.openjdk.java.net/%7Eanoll/8036851/webrev.00/>
>>>>>>>
>>>>>>> *Tests*
>>>>>>> JPRT
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>>
>>>>>
>

From vladimir.kozlov at oracle.com  Tue May  6 07:06:52 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 06 May 2014 00:06:52 -0700
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <5368870E.4080901@oracle.com>
References: <53638C6B.10600@oracle.com>	<212507C6-507A-4813-B796-42413A5D9A14@oracle.com>	<53673794.20809@oracle.com>
	<53674C50.4010008@oracle.com>	<53676DED.4030807@oracle.com>	<71396864-167A-4996-9146-7F8E7769C73F@oracle.com>
	<5368870E.4080901@oracle.com>
Message-ID: <53688A0C.30804@oracle.com>

Looks fine to me too.

Vladimir

On 5/5/14 11:54 PM, Tobias Hartmann wrote:
> Hi Chris,
>
> thanks for the review. Do I need a second one?
>
> Best,
> Tobias
>
> On 06.05.2014 02:26, Christian Thalinger wrote:
>> Looks good.
>>
>> On May 5, 2014, at 12:54 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>>
>>> Hi Niclas,
>>>
>>> thanks for the feedback.
>>>
>>> On 05.05.2014 10:31, Niclas Adlertz wrote:
>>>> Minor thing:
>>>> bool require_atomic_access()       { return _require_atomic_access; }
>>>> could be defined as:
>>>> bool require_atomic_access() const { return _require_atomic_access; }
>>>>
>>>> You could also change that for LoadL/StoreL while you are at it :)
>>> Done.
>>>
>>> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.02/
>>>
>>> Thanks,
>>> Tobias
>>>
>>>> Kind Regards,
>>>> Niclas Adlertz
>>>>
>>>> On 05/05/2014 09:02 AM, Tobias Hartmann wrote:
>>>>> Hi Christian,
>>>>>
>>>>> thanks for the review.
>>>>>
>>>>> On 05/02/2014 09:23 PM, Christian Thalinger wrote:
>>>>>> *src/share/vm/opto/memnode.hpp:*
>>>>>> *
>>>>>> *
>>>>>> *+   #ifndef PRODUCT*
>>>>>> *+     virtual void dump_spec(outputStream *st) const {*
>>>>>> *+       LoadNode::dump_spec(st);*
>>>>>> *+       if (_require_atomic_access)  st->print(" Atomic!");*
>>>>>> *+     }*
>>>>>> *+   #endif*
>>>>>>
>>>>>> Indent is wrong.
>>>>> I missed that, thanks!
>>>>>
>>>>> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.01/
>>>>>
>>>>> Best regards,
>>>>> Tobias
>>>>>
>>>>>> Otherwise this looks good.
>>>>>>
>>>>>> On May 2, 2014, at 2:15 AM, Tobias Hartmann
>>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> please review the following patch for bug 8036851.
>>>>>>>
>>>>>>> *Problem*
>>>>>>> Volatile double accesses are not treated different from normal
>>>>>>> accesses in the C2 compiler with respect to atomicity because on x86
>>>>>>> and sparc double accesses were always atomic. However, this may not
>>>>>>> be case on other architectures. On an architecture where there are
>>>>>>> atomic and non-atomic double accesses, we would have to implement all
>>>>>>> accesses to be atomic, because the C2 compiler does not distinguish
>>>>>>> between the two cases.
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
>>>>>>>
>>>>>>> *Solution*
>>>>>>> The C2 structure is adapted to distinguish between volatile and
>>>>>>> non-volatile double accesses.
>>>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/
>>>>>>> <http://cr.openjdk.java.net/%7Eanoll/8036851/webrev.00/>
>>>>>>>
>>>>>>> *Tests*
>>>>>>> JPRT
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>>
>>>>>
>

From tobias.hartmann at oracle.com  Tue May  6 07:09:18 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 06 May 2014 09:09:18 +0200
Subject: [9] RFR(S): 8036851: volatile double accesses are not explicitly
	atomic in C2
In-Reply-To: <53688A0C.30804@oracle.com>
References: <53638C6B.10600@oracle.com>	<212507C6-507A-4813-B796-42413A5D9A14@oracle.com>	<53673794.20809@oracle.com>	<53674C50.4010008@oracle.com>	<53676DED.4030807@oracle.com>	<71396864-167A-4996-9146-7F8E7769C73F@oracle.com>	<5368870E.4080901@oracle.com>
	<53688A0C.30804@oracle.com>
Message-ID: <53688A9E.8070402@oracle.com>

Vladimir, Niclas, thanks for the reviews.

Tobias

On 06.05.2014 09:06, Vladimir Kozlov wrote:
> Looks fine to me too.
>
> Vladimir
>
> On 5/5/14 11:54 PM, Tobias Hartmann wrote:
>> Hi Chris,
>>
>> thanks for the review. Do I need a second one?
>>
>> Best,
>> Tobias
>>
>> On 06.05.2014 02:26, Christian Thalinger wrote:
>>> Looks good.
>>>
>>> On May 5, 2014, at 12:54 AM, Tobias Hartmann 
>>> <tobias.hartmann at oracle.com> wrote:
>>>
>>>> Hi Niclas,
>>>>
>>>> thanks for the feedback.
>>>>
>>>> On 05.05.2014 10:31, Niclas Adlertz wrote:
>>>>> Minor thing:
>>>>> bool require_atomic_access()       { return _require_atomic_access; }
>>>>> could be defined as:
>>>>> bool require_atomic_access() const { return _require_atomic_access; }
>>>>>
>>>>> You could also change that for LoadL/StoreL while you are at it :)
>>>> Done.
>>>>
>>>> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.02/
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>> Kind Regards,
>>>>> Niclas Adlertz
>>>>>
>>>>> On 05/05/2014 09:02 AM, Tobias Hartmann wrote:
>>>>>> Hi Christian,
>>>>>>
>>>>>> thanks for the review.
>>>>>>
>>>>>> On 05/02/2014 09:23 PM, Christian Thalinger wrote:
>>>>>>> *src/share/vm/opto/memnode.hpp:*
>>>>>>> *
>>>>>>> *
>>>>>>> *+   #ifndef PRODUCT*
>>>>>>> *+     virtual void dump_spec(outputStream *st) const {*
>>>>>>> *+       LoadNode::dump_spec(st);*
>>>>>>> *+       if (_require_atomic_access)  st->print(" Atomic!");*
>>>>>>> *+     }*
>>>>>>> *+   #endif*
>>>>>>>
>>>>>>> Indent is wrong.
>>>>>> I missed that, thanks!
>>>>>>
>>>>>> New webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.01/
>>>>>>
>>>>>> Best regards,
>>>>>> Tobias
>>>>>>
>>>>>>> Otherwise this looks good.
>>>>>>>
>>>>>>> On May 2, 2014, at 2:15 AM, Tobias Hartmann
>>>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> please review the following patch for bug 8036851.
>>>>>>>>
>>>>>>>> *Problem*
>>>>>>>> Volatile double accesses are not treated different from normal
>>>>>>>> accesses in the C2 compiler with respect to atomicity because 
>>>>>>>> on x86
>>>>>>>> and sparc double accesses were always atomic. However, this may 
>>>>>>>> not
>>>>>>>> be case on other architectures. On an architecture where there are
>>>>>>>> atomic and non-atomic double accesses, we would have to 
>>>>>>>> implement all
>>>>>>>> accesses to be atomic, because the C2 compiler does not 
>>>>>>>> distinguish
>>>>>>>> between the two cases.
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8036851
>>>>>>>>
>>>>>>>> *Solution*
>>>>>>>> The C2 structure is adapted to distinguish between volatile and
>>>>>>>> non-volatile double accesses.
>>>>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8036851/webrev.00/
>>>>>>>> <http://cr.openjdk.java.net/%7Eanoll/8036851/webrev.00/>
>>>>>>>>
>>>>>>>> *Tests*
>>>>>>>> JPRT
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>>
>>>>>>
>>


From albert.noll at oracle.com  Tue May  6 07:12:23 2014
From: albert.noll at oracle.com (Albert)
Date: Tue, 06 May 2014 09:12:23 +0200
Subject: [9] RFR(XS): 8042428: CompileQueue::free_all() code is incorrect
Message-ID: <53688B57.5030109@oracle.com>

Hi all,

could I get reviews for this small patch?

Bug:
https://bugs.openjdk.java.net/browse/JDK-8042428

Problem:
The loop in CompileQueue::free_all() is incorrect because 
CompileTask::_next field is overwritten by CompileTask::free().

Solution:
Free task after getting next pointer of freelist.

Webrev:
http://cr.openjdk.java.net/~anoll/8042428/webrev.00/


Many thanks in advance,
Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140506/72802f62/attachment.html>

From forax at univ-mlv.fr  Tue May  6 07:14:14 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 06 May 2014 09:14:14 +0200
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
Message-ID: <53688BC6.1090802@univ-mlv.fr>

On 05/06/2014 04:44 AM, Igor Veresov wrote:
> The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows:
>
> 1. Initially a method is compiled as usual (no instrumentation, no overhead).
> 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code.
> 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter.
> 4. The value of the counter is then used by the sweeper to determine is the method is in fact used.
> 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again.
>
> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>
> Testing:
> - jprt,
> - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations.
>
> igor

Hi Igor,
a stupid idea, instead of deoptimizing when the aging code is installed 
and you detect that the method is hot,
you can shift the method entry pointer to the instruction after the the 
code that decrement the aging value
and insert a goto instead of the first instruction in case you come from 
the entry to does the vtable check entry point.

cheers,
R?mi


From niclas.adlertz at oracle.com  Tue May  6 07:26:18 2014
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Tue, 06 May 2014 09:26:18 +0200
Subject: [9] RFR(XS): 8042428: CompileQueue::free_all() code is incorrect
In-Reply-To: <53688B57.5030109@oracle.com>
References: <53688B57.5030109@oracle.com>
Message-ID: <53688E9A.4050802@oracle.com>

That looks good to me.

Kind Regards,
Niclas Adlertz

On 05/06/2014 09:12 AM, Albert wrote:
> Hi all,
>
> could I get reviews for this small patch?
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8042428
>
> Problem:
> The loop in CompileQueue::free_all() is incorrect because
> CompileTask::_next field is overwritten by CompileTask::free().
>
> Solution:
> Free task after getting next pointer of freelist.
>
> Webrev:
> http://cr.openjdk.java.net/~anoll/8042428/webrev.00/
>
>
> Many thanks in advance,
> Albert
>

From tobias.hartmann at oracle.com  Tue May  6 07:27:08 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 06 May 2014 09:27:08 +0200
Subject: [9] RFR(S): 8029343: CodeCache::allocate increments '_number_of_blobs'
	even if allocation fails.
Message-ID: <53688ECC.5020308@oracle.com>

Hi,

please review the following patch for bug 8029343.

*Problem:*
(1) CodeCache::allocate(...) increments _number_of_blobs before the 
actual allocation is performed. In case the allocation fails the counter 
is set to a wrong value.
(2) The guarantee(size >= 0, ...) is incorrect. Calling 
CodeCache::allocate(...) with size = 0 leads to a segmentation fault. 
Further, a guarantee is too strong here. We can simply return NULL at 
runtime if the size is <= 0.
Bug: https://bugs.openjdk.java.net/browse/JDK-8029343

*Solution:*
(1) The increment is moved after the allocation.
(2) An assert is used instead of the guarantee and NULL is returned if 
size <= 0.
Webrev: http://cr.openjdk.java.net/~anoll/8029343/webrev.00/

Thanks,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140506/f53752c8/attachment.html>

From albert.noll at oracle.com  Tue May  6 07:29:33 2014
From: albert.noll at oracle.com (Albert)
Date: Tue, 06 May 2014 09:29:33 +0200
Subject: [9] RFR(XS): 8042428: CompileQueue::free_all() code is incorrect
In-Reply-To: <53688E9A.4050802@oracle.com>
References: <53688B57.5030109@oracle.com> <53688E9A.4050802@oracle.com>
Message-ID: <53688F5D.3020200@oracle.com>

Niclas, thanks for looking at this.

Best,
Albert

On 05/06/2014 09:26 AM, Niclas Adlertz wrote:
> That looks good to me.
>
> Kind Regards,
> Niclas Adlertz
>
> On 05/06/2014 09:12 AM, Albert wrote:
>> Hi all,
>>
>> could I get reviews for this small patch?
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8042428
>>
>> Problem:
>> The loop in CompileQueue::free_all() is incorrect because
>> CompileTask::_next field is overwritten by CompileTask::free().
>>
>> Solution:
>> Free task after getting next pointer of freelist.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~anoll/8042428/webrev.00/
>>
>>
>> Many thanks in advance,
>> Albert
>>


From vladimir.kozlov at oracle.com  Tue May  6 07:31:47 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 06 May 2014 00:31:47 -0700
Subject: [9] RFR(XS): 8042428: CompileQueue::free_all() code is incorrect
In-Reply-To: <53688B57.5030109@oracle.com>
References: <53688B57.5030109@oracle.com>
Message-ID: <53688FE3.60908@oracle.com>

Good.

Vladimir

On 5/6/14 12:12 AM, Albert wrote:
> Hi all,
>
> could I get reviews for this small patch?
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8042428
>
> Problem:
> The loop in CompileQueue::free_all() is incorrect because CompileTask::_next field is overwritten by CompileTask::free().
>
> Solution:
> Free task after getting next pointer of freelist.
>
> Webrev:
> http://cr.openjdk.java.net/~anoll/8042428/webrev.00/
>
>
> Many thanks in advance,
> Albert

From igor.veresov at oracle.com  Tue May  6 07:34:18 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 6 May 2014 00:34:18 -0700
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <53688BC6.1090802@univ-mlv.fr>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
	<53688BC6.1090802@univ-mlv.fr>
Message-ID: <8C4F3D66-B510-41E3-B873-8711150555EE@oracle.com>

Remi,

Right, we can do patching. But this deopt is more of a failsafe for the exceptional situation in case the method radically changes its behavior. And I didn?t want to do platform-specific stuff for the edge case. But, yes, we can patch and jump over it if recompilation of that sort becomes a performance problem. 

igor

On May 6, 2014, at 12:14 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 05/06/2014 04:44 AM, Igor Veresov wrote:
>> The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows:
>> 
>> 1. Initially a method is compiled as usual (no instrumentation, no overhead).
>> 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code.
>> 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter.
>> 4. The value of the counter is then used by the sweeper to determine is the method is in fact used.
>> 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again.
>> 
>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>> 
>> Testing:
>> - jprt,
>> - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations.
>> 
>> igor
> 
> Hi Igor,
> a stupid idea, instead of deoptimizing when the aging code is installed and you detect that the method is hot,
> you can shift the method entry pointer to the instruction after the the code that decrement the aging value
> and insert a goto instead of the first instruction in case you come from the entry to does the vtable check entry point.
> 
> cheers,
> R?mi
> 


From albert.noll at oracle.com  Tue May  6 07:36:54 2014
From: albert.noll at oracle.com (Albert)
Date: Tue, 06 May 2014 09:36:54 +0200
Subject: [9] RFR(XS): 8042428: CompileQueue::free_all() code is incorrect
In-Reply-To: <53688FE3.60908@oracle.com>
References: <53688B57.5030109@oracle.com> <53688FE3.60908@oracle.com>
Message-ID: <53689116.6020009@oracle.com>

Vladimir, thanks for looking at this.

I guess the change is simple enough so that I can
push it.

Best,
Albert


On 05/06/2014 09:31 AM, Vladimir Kozlov wrote:
> Good.
>
> Vladimir
>
> On 5/6/14 12:12 AM, Albert wrote:
>> Hi all,
>>
>> could I get reviews for this small patch?
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8042428
>>
>> Problem:
>> The loop in CompileQueue::free_all() is incorrect because 
>> CompileTask::_next field is overwritten by CompileTask::free().
>>
>> Solution:
>> Free task after getting next pointer of freelist.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~anoll/8042428/webrev.00/
>>
>>
>> Many thanks in advance,
>> Albert


From vladimir.kozlov at oracle.com  Tue May  6 07:38:14 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 06 May 2014 00:38:14 -0700
Subject: [9] RFR(XS): 8042428: CompileQueue::free_all() code is incorrect
In-Reply-To: <53689116.6020009@oracle.com>
References: <53688B57.5030109@oracle.com> <53688FE3.60908@oracle.com>
	<53689116.6020009@oracle.com>
Message-ID: <53689166.20303@oracle.com>

On 5/6/14 12:36 AM, Albert wrote:
> Vladimir, thanks for looking at this.
>
> I guess the change is simple enough so that I can push it.

Yes.

Vladimir

>
> Best,
> Albert
>
>
> On 05/06/2014 09:31 AM, Vladimir Kozlov wrote:
>> Good.
>>
>> Vladimir
>>
>> On 5/6/14 12:12 AM, Albert wrote:
>>> Hi all,
>>>
>>> could I get reviews for this small patch?
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8042428
>>>
>>> Problem:
>>> The loop in CompileQueue::free_all() is incorrect because CompileTask::_next field is overwritten by
>>> CompileTask::free().
>>>
>>> Solution:
>>> Free task after getting next pointer of freelist.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~anoll/8042428/webrev.00/
>>>
>>>
>>> Many thanks in advance,
>>> Albert
>

From vladimir.kozlov at oracle.com  Tue May  6 07:41:43 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 06 May 2014 00:41:43 -0700
Subject: [9] RFR(S): 8029343: CodeCache::allocate increments
	'_number_of_blobs' even if allocation fails.
In-Reply-To: <53688ECC.5020308@oracle.com>
References: <53688ECC.5020308@oracle.com>
Message-ID: <53689237.9090609@oracle.com>

Parfait may complain about returning NULL and without guarantee.
Please, test.

Thanks,
Vladimir

On 5/6/14 12:27 AM, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch for bug 8029343.
>
> *Problem:*
> (1) CodeCache::allocate(...) increments _number_of_blobs before the actual allocation is performed. In case the
> allocation fails the counter is set to a wrong value.
> (2) The guarantee(size >= 0, ...) is incorrect. Calling CodeCache::allocate(...) with size = 0 leads to a segmentation
> fault. Further, a guarantee is too strong here. We can simply return NULL at runtime if the size is <= 0.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8029343
>
> *Solution:*
> (1) The increment is moved after the allocation.
> (2) An assert is used instead of the guarantee and NULL is returned if size <= 0.
> Webrev: http://cr.openjdk.java.net/~anoll/8029343/webrev.00/
>
> Thanks,
> Tobias

From igor.veresov at oracle.com  Tue May  6 07:41:48 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 6 May 2014 00:41:48 -0700
Subject: [9] RFR(S): 8029343: CodeCache::allocate increments
	'_number_of_blobs' even if allocation fails.
In-Reply-To: <53688ECC.5020308@oracle.com>
References: <53688ECC.5020308@oracle.com>
Message-ID: <BF34CB10-76ED-4765-8662-1699C588E8B7@oracle.com>

BufferBlob::operator new() doesn?t seem to be quite ready to see the NULL return. Could we put some error handling in there? Like a call to fatal() similar to other places. Otherwise looks good.

igor

On May 6, 2014, at 12:27 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi,
> 
> please review the following patch for bug 8029343.
> 
> Problem:
> (1) CodeCache::allocate(...) increments _number_of_blobs before the actual allocation is performed. In case the allocation fails the counter is set to a wrong value.
> (2) The guarantee(size >= 0, ...) is incorrect. Calling CodeCache::allocate(...) with size = 0 leads to a segmentation fault. Further, a guarantee is too strong here. We can simply return NULL at runtime if the size is <= 0.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8029343
> 
> Solution:
> (1) The increment is moved after the allocation.
> (2) An assert is used instead of the guarantee and NULL is returned if size <= 0.
> Webrev: http://cr.openjdk.java.net/~anoll/8029343/webrev.00/
> 
> Thanks,
> Tobias


From paul.sandoz at oracle.com  Tue May  6 08:14:45 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 6 May 2014 10:14:45 +0200
Subject: Request for Reviews (S): JDK-8003585 strength reduce or eliminate
	range checks for power-of-two sized arrays
In-Reply-To: <CA+cQ+tQ2FoMhSj_B-Q=zgv3sGtJo9HojhWDsEWkx-UThc+mqEA@mail.gmail.com>
References: <CA+cQ+tR5c3y3uLpdO2Gop-RA0ZPJ4Mmq9yAAK5dOpFtgv-XPcg@mail.gmail.com>
	<440F2280-4B25-4AE6-A4F6-DDD4EB529636@oracle.com>
	<52FC129D.7040409@oracle.com>
	<CA+cQ+tTzA822citeYM0zCNE3FDyBk9hTO2h2i6POiJWSar6hVA@mail.gmail.com>
	<CA+cQ+tTWkkJHwcvJ4R=f31ve9vRwG5TfizHfo56sO9R3p3sRcQ@mail.gmail.com>
	<52FE6A08.20400@oracle.com>
	<CA+cQ+tQ00O1bT0JAAX9Lk+hPrfLV0PgQoiO1wmEUbKrPrqi1kA@mail.gmail.com>
	<52FE7313.3060404@oracle.com> <530209A8.1020501@oracle.com>
	<DC638183-2429-4FD2-B455-F87C0FD7EBFE@oracle.com>
	<CA+cQ+tQ2FoMhSj_B-Q=zgv3sGtJo9HojhWDsEWkx-UThc+mqEA@mail.gmail.com>
Message-ID: <38EE6922-0B9C-49A6-B54D-E78BA0EFECB1@oracle.com>


On May 5, 2014, at 9:10 PM, Krystal Mok <rednaxelafx at gmail.com> wrote:

> Hi Paul,
> 
> Oops, my bad. I've been busy with my day work and hadn't got around to write a test case for this patch, that's what caused the delay. I can try to come up with a test case later this week if you can wait.
> 

Thanks!

Also, if you have any spare time left over any hints/guidance on [1] would be greatly appreciated.

Paul.

[1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-May/014365.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140506/7424405b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140506/7424405b/signature-0001.asc>

From david.simms at oracle.com  Tue May  6 09:05:18 2014
From: david.simms at oracle.com (David Simms)
Date: Tue, 06 May 2014 11:05:18 +0200
Subject: RFR (S) JDK-6311046: -Xcheck:jni should support checking of
	GetPrimitiveArrayCritical
In-Reply-To: <5367FB03.7000302@oracle.com>
References: <53677804.70700@oracle.com> <5367FB03.7000302@oracle.com>
Message-ID: <5368A5CE.7030807@oracle.com>


Dropped compileBroker.cpp (have marked 8042428 with appropriate rules), 
updated patch here:

http://cr.openjdk.java.net/~dsimms/6311046/rev3/

On 5/05/2014 10:56 p.m., Vladimir Kozlov wrote:
> Hi David,
>
> compileBroker.cpp was recently modified by 8040798 (it was pushed into 
> main repo today):
>
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/48c15b47a4f1
>
> And it still has the problem you pointed (overwrite _next pointer). I 
> think it should be a separate fix since we don't delete the task 
> object now but put it on free list. I will file a bug. Please, remove 
> this change from yours.
>
> Thanks,
> Vladimir
>
> On 5/5/14 4:37 AM, David Simms wrote:
>> Gidday all:
>>
>> Bug/Enhancement: https://bugs.openjdk.java.net/browse/JDK-6311046
>>
>> Web review: http://cr.openjdk.java.net/~dsimms/6311046/rev2/
>>
>> Cleaned up the "hand rolled" memory bounds checking in
>> os::malloc/realloc/free and type checking in checked JNI (GetString*),
>> and unified into a single helper class "FencedMemory". Added some extra
>> checks to checked JNI (release mode).
>>
>> There is now some extra debugging support for free/release operations,
>> FencedMemory::release_for_freeing()" will now mark user bytes with
>> "freeBlockPad", which did yeld a result when testing:
>>
>> Found a minor bug in CompilerQueue (hence CC compiler ML), shouldn't be
>> a problem in practice (probably won't crash), but the code is
>> incorrect...and now fixed here.
>>
>> Testing Completed:
>>
>> Ran on all platforms:
>>
>>   * JPRT
>>   * jteg jdk_core & jdk_svc
>>   * "RT nightly".
>>
>>
>> Cheers
>> /David Simms


From david.holmes at oracle.com  Tue May  6 10:36:49 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 06 May 2014 20:36:49 +1000
Subject: RFR (S) JDK-6311046: -Xcheck:jni should support checking of
	GetPrimitiveArrayCritical
In-Reply-To: <5368A5CE.7030807@oracle.com>
References: <53677804.70700@oracle.com> <5367FB03.7000302@oracle.com>
	<5368A5CE.7030807@oracle.com>
Message-ID: <5368BB41.6020007@oracle.com>

Hi David,

Is this "fenced memory" terminology in common use? I'm more used to 
"memory fences" - which is quite a different thing.

David H.

On 6/05/2014 7:05 PM, David Simms wrote:
>
> Dropped compileBroker.cpp (have marked 8042428 with appropriate rules),
> updated patch here:
>
> http://cr.openjdk.java.net/~dsimms/6311046/rev3/
>
> On 5/05/2014 10:56 p.m., Vladimir Kozlov wrote:
>> Hi David,
>>
>> compileBroker.cpp was recently modified by 8040798 (it was pushed into
>> main repo today):
>>
>> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/48c15b47a4f1
>>
>> And it still has the problem you pointed (overwrite _next pointer). I
>> think it should be a separate fix since we don't delete the task
>> object now but put it on free list. I will file a bug. Please, remove
>> this change from yours.
>>
>> Thanks,
>> Vladimir
>>
>> On 5/5/14 4:37 AM, David Simms wrote:
>>> Gidday all:
>>>
>>> Bug/Enhancement: https://bugs.openjdk.java.net/browse/JDK-6311046
>>>
>>> Web review: http://cr.openjdk.java.net/~dsimms/6311046/rev2/
>>>
>>> Cleaned up the "hand rolled" memory bounds checking in
>>> os::malloc/realloc/free and type checking in checked JNI (GetString*),
>>> and unified into a single helper class "FencedMemory". Added some extra
>>> checks to checked JNI (release mode).
>>>
>>> There is now some extra debugging support for free/release operations,
>>> FencedMemory::release_for_freeing()" will now mark user bytes with
>>> "freeBlockPad", which did yeld a result when testing:
>>>
>>> Found a minor bug in CompilerQueue (hence CC compiler ML), shouldn't be
>>> a problem in practice (probably won't crash), but the code is
>>> incorrect...and now fixed here.
>>>
>>> Testing Completed:
>>>
>>> Ran on all platforms:
>>>
>>>   * JPRT
>>>   * jteg jdk_core & jdk_svc
>>>   * "RT nightly".
>>>
>>>
>>> Cheers
>>> /David Simms
>

From fweimer at redhat.com  Tue May  6 10:51:16 2014
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 06 May 2014 12:51:16 +0200
Subject: RFR (S) JDK-6311046: -Xcheck:jni should support checking of
	GetPrimitiveArrayCritical
In-Reply-To: <53677804.70700@oracle.com>
References: <53677804.70700@oracle.com>
Message-ID: <5368BEA4.2030201@redhat.com>

On 05/05/2014 01:37 PM, David Simms wrote:
> Gidday all:
>
> Bug/Enhancement: https://bugs.openjdk.java.net/browse/JDK-6311046
>
> Web review: http://cr.openjdk.java.net/~dsimms/6311046/rev2/
>
> Cleaned up the "hand rolled" memory bounds checking in
> os::malloc/realloc/free and type checking in checked JNI (GetString*),
> and unified into a single helper class "FencedMemory". Added some extra
> checks to checked JNI (release mode).

The name is a bit unfortunate because it's not related to memory fences 
at all. :-)

   60  * <code>
   61  *   Thing* alloc_thing() {
   62  *    void* mem = alloc_fn(sizeof(thing) + 
FencedMemory::get_total_size());
   63  *    FencedMemory fenced(mem, sizeof(thing));
   64  *    return (Thing*) fenced.get_user_ptr();
   65  *   }
   66  * </code>

I don't like this interface because it pushes overflow checking into 
client code.  There is get_total_size(size_t) which asserts on 
wraparound, which seems marginally saner.  Something that performs the 
allocation internally would better, but this would seem to need a callback.

Technicaly, FencedMemory::Fence::FENCE_SIZE needs a definition.  You 
could avoid this by using an enum constant.

-- 
Florian Weimer / Red Hat Product Security Team

From kevin.walls at oracle.com  Tue May  6 11:50:59 2014
From: kevin.walls at oracle.com (Kevin Walls)
Date: Tue, 06 May 2014 12:50:59 +0100
Subject: [7] RFR(S): 8042250: Misleading command line output for
	ReservedCodeCacheSize validation
In-Reply-To: <5367BE30.3050205@oracle.com>
References: <53677695.7080702@oracle.com>
	<980cc9cf-6a17-4093-985a-0c57855f24b4@default>
	<5367BE30.3050205@oracle.com>
Message-ID: <5368CCA3.2060605@oracle.com>


Sure - we can get that into 7u-dev (I'll do it, via the 7u-dev mailing 
list for open approval...).

Thanks
Kevin

On 05/05/14 17:37, Vladimir Kozlov wrote:
> You can count me as Reviewer for this fix.
>
> Thanks,
> Vladimir K
>
> On 5/5/14 8:20 AM, Mattis Castegren wrote:
>> Hi
>>
>> I'm not a committer. Forwarding this to Kevin. Kevin, could you look 
>> at this and push it?
>>
>> We will also need a code review from an official reviewer. The fix is 
>> VERY small, as it only changes one line of output. Anyone who could 
>> review it right away?
>>
>> Kind Regards
>> /Mattis
>>
>> -----Original Message-----
>> From: Tobias Hartmann
>> Sent: den 5 maj 2014 13:32
>> To: Mattis Castegren; Vladimir Kozlov
>> Cc: hotspot compiler
>> Subject: [7] RFR(S): 8042250: Misleading command line output for 
>> ReservedCodeCacheSize validation
>>
>> Hi Mattis,
>>
>> bug [1] is fixed in JDK 8 and 9 by the fix for [2] but still occurs in
>> JDK 7.
>>
>> Please review and push the following small patch that fixes the bug in
>> JDK 7.
>> Webrev: http://cr.openjdk.java.net/~anoll/8042250/webrev.00/
>>
>> Thanks,
>> Tobias
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8042250
>> [2] https://bugs.openjdk.java.net/browse/JDK-8014972
>>


From albert.noll at oracle.com  Tue May  6 12:43:19 2014
From: albert.noll at oracle.com (Albert)
Date: Tue, 06 May 2014 14:43:19 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails with:
	Test Failed: AddVI 0 < 4
Message-ID: <5368D8E7.6000800@oracle.com>

Hi all,

could I get reviews for this patch?

Bug:
https://bugs.openjdk.java.net/browse/JDK-8042431

Problem:
The minimum number of compiler threads is set incorrectly.

Solution:
Define a new function 'get_min_number_of_compiler_threads()' that
determines the minimum number of compiler threads  for a particular
platform/configuration.

Testing:
Failing test case; zero; -XX:-TieredCompilation -XX:CICompilerCount=1

Webrev:
http://cr.openjdk.java.net/~anoll/8042431/webrev.00/

Many thanks in advance,
Albert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140506/7fdeda2b/attachment.html>

From tobias.hartmann at oracle.com  Tue May  6 12:44:18 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 06 May 2014 14:44:18 +0200
Subject: [9] RFR(S): 8029343: CodeCache::allocate increments
	'_number_of_blobs' even if allocation fails.
In-Reply-To: <53689237.9090609@oracle.com>
References: <53688ECC.5020308@oracle.com> <53689237.9090609@oracle.com>
Message-ID: <5368D922.8060600@oracle.com>

Hi Vladimir,

On 06.05.2014 09:41, Vladimir Kozlov wrote:
> Parfait may complain about returning NULL and without guarantee.
> Please, test.

I tested the implementation with parfait and no new defects showed up.

Thanks,
Tobias

> Thanks,
> Vladimir
>
> On 5/6/14 12:27 AM, Tobias Hartmann wrote:
>> Hi,
>>
>> please review the following patch for bug 8029343.
>>
>> *Problem:*
>> (1) CodeCache::allocate(...) increments _number_of_blobs before the 
>> actual allocation is performed. In case the
>> allocation fails the counter is set to a wrong value.
>> (2) The guarantee(size >= 0, ...) is incorrect. Calling 
>> CodeCache::allocate(...) with size = 0 leads to a segmentation
>> fault. Further, a guarantee is too strong here. We can simply return 
>> NULL at runtime if the size is <= 0.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029343
>>
>> *Solution:*
>> (1) The increment is moved after the allocation.
>> (2) An assert is used instead of the guarantee and NULL is returned 
>> if size <= 0.
>> Webrev: http://cr.openjdk.java.net/~anoll/8029343/webrev.00/
>>
>> Thanks,
>> Tobias


From tobias.hartmann at oracle.com  Tue May  6 12:49:39 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 06 May 2014 14:49:39 +0200
Subject: [9] RFR(S): 8029343: CodeCache::allocate increments
	'_number_of_blobs' even if allocation fails.
In-Reply-To: <BF34CB10-76ED-4765-8662-1699C588E8B7@oracle.com>
References: <53688ECC.5020308@oracle.com>
	<BF34CB10-76ED-4765-8662-1699C588E8B7@oracle.com>
Message-ID: <5368DA63.20107@oracle.com>

Hi Igor,

On 06.05.2014 09:41, Igor Veresov wrote:
> BufferBlob::operator new() doesn?t seem to be quite ready to see the NULL return. Could we put some error handling in there? Like a call to fatal() similar to other places. Otherwise looks good.

I would suggest we fix this together with [1]. NULL is already returned 
in case the allocation in the code cache fails. A call to fatal() is not 
appropriate here, because the sweeper may solve the problem by freeing 
space in the code cache.

Thanks,
Tobias

[1] https://bugs.openjdk.java.net/browse/JDK-8022968

> igor
>
> On May 6, 2014, at 12:27 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>
>> Hi,
>>
>> please review the following patch for bug 8029343.
>>
>> Problem:
>> (1) CodeCache::allocate(...) increments _number_of_blobs before the actual allocation is performed. In case the allocation fails the counter is set to a wrong value.
>> (2) The guarantee(size >= 0, ...) is incorrect. Calling CodeCache::allocate(...) with size = 0 leads to a segmentation fault. Further, a guarantee is too strong here. We can simply return NULL at runtime if the size is <= 0.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029343
>>
>> Solution:
>> (1) The increment is moved after the allocation.
>> (2) An assert is used instead of the guarantee and NULL is returned if size <= 0.
>> Webrev: http://cr.openjdk.java.net/~anoll/8029343/webrev.00/
>>
>> Thanks,
>> Tobias


From niclas.adlertz at oracle.com  Tue May  6 13:04:30 2014
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Tue, 06 May 2014 15:04:30 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <5368D8E7.6000800@oracle.com>
References: <5368D8E7.6000800@oracle.com>
Message-ID: <5368DDDE.7020908@oracle.com>

Hi Albert,

Inside src/share/vm/runtime/arguments.cpp:
+   // We should not come here. However, we also do not fail the VM, 
since this is a not-critical error.
+   assert (false, "Missed configuration to set the minimum number of 
compiler threads.");
+   // Return 2, since this works with all configurations on all platforms.
+   return 2;

That is dead code, and we can remove it.
If none of the cases 1, 2 or 3 are true, we will always enter case 4.

Kind Regards,
Niclas Adlertz

On 05/06/2014 02:43 PM, Albert wrote:
> Hi all,
>
> could I get reviews for this patch?
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8042431
>
> Problem:
> The minimum number of compiler threads is set incorrectly.
>
> Solution:
> Define a new function 'get_min_number_of_compiler_threads()' that
> determines the minimum number of compiler threads  for a particular
> platform/configuration.
>
> Testing:
> Failing test case; zero; -XX:-TieredCompilation -XX:CICompilerCount=1
>
> Webrev:
> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>
> Many thanks in advance,
> Albert
>
>

From niclas.adlertz at oracle.com  Tue May  6 13:21:01 2014
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Tue, 06 May 2014 15:21:01 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <5368DDDE.7020908@oracle.com>
References: <5368D8E7.6000800@oracle.com> <5368DDDE.7020908@oracle.com>
Message-ID: <5368E1BD.6040608@oracle.com>

Just a suggestion, but personally I would find this easier to read:

// case 1
if (no_compiler) {
   return 0;
}

// case 2 or 3
if (!TieredCompilation || TieredStopAtLevel < CompLevel_full_optimization) {
   return 1;
}

// case 4
return 2;

Kind Regards,
Niclas Adlertz

On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
> Hi Albert,
>
> Inside src/share/vm/runtime/arguments.cpp:
> +   // We should not come here. However, we also do not fail the VM,
> since this is a not-critical error.
> +   assert (false, "Missed configuration to set the minimum number of
> compiler threads.");
> +   // Return 2, since this works with all configurations on all platforms.
> +   return 2;
>
> That is dead code, and we can remove it.
> If none of the cases 1, 2 or 3 are true, we will always enter case 4.
>
> Kind Regards,
> Niclas Adlertz
>
> On 05/06/2014 02:43 PM, Albert wrote:
>> Hi all,
>>
>> could I get reviews for this patch?
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>
>> Problem:
>> The minimum number of compiler threads is set incorrectly.
>>
>> Solution:
>> Define a new function 'get_min_number_of_compiler_threads()' that
>> determines the minimum number of compiler threads  for a particular
>> platform/configuration.
>>
>> Testing:
>> Failing test case; zero; -XX:-TieredCompilation -XX:CICompilerCount=1
>>
>> Webrev:
>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>
>> Many thanks in advance,
>> Albert
>>
>>

From zhengyu.gu at oracle.com  Tue May  6 12:47:45 2014
From: zhengyu.gu at oracle.com (Zhengyu Gu)
Date: Tue, 06 May 2014 08:47:45 -0400
Subject: RFR(XS) 8041415: remove port.{cpp,hpp} files
In-Reply-To: <5367F65A.6090906@oracle.com>
References: <5367F2D5.4080606@oracle.com> <5367F65A.6090906@oracle.com>
Message-ID: <5368D9F1.3010306@oracle.com>

Vladimir,

Thanks for pointing out.

At this point, I would like to withdraw this request, and will resubmit 
it after Lois' changes get in.

-Zhengyu


On 5/5/2014 4:36 PM, Vladimir Kozlov wrote:
> CC to compiler alias since you changing our code.
>
> Copyright year change should be 2014.
>
> FileBuffRegion removal is done under separate bug 8041620 by Lois 
> Foltan, the review was sent today today.
>
> domgraph.cpp, output.cpp: use max_juint instead of (uint) -1.
>
> Thanks,
> Vladimir
>
> On 5/5/14 1:21 PM, Zhengyu Gu wrote:
>> This is a code cleanup based on attached patch from Christian Thalinger.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041415
>> Webrev:
>
>  http://cr.openjdk.java.net/~zgu/8041415/webrev.00/
>
>>
>> Test:
>>    JPRT
>>
>> Thanks,
>>


From albert.noll at oracle.com  Tue May  6 13:21:56 2014
From: albert.noll at oracle.com (Albert)
Date: Tue, 06 May 2014 15:21:56 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <5368DDDE.7020908@oracle.com>
References: <5368D8E7.6000800@oracle.com> <5368DDDE.7020908@oracle.com>
Message-ID: <5368E1F4.50308@oracle.com>

Hi Niclas,

thanks for looking at this. Please see comment inline.
On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
> Hi Albert,
>
> Inside src/share/vm/runtime/arguments.cpp:
> +   // We should not come here. However, we also do not fail the VM, 
> since this is a not-critical error.
> +   assert (false, "Missed configuration to set the minimum number of 
> compiler threads.");
> +   // Return 2, since this works with all configurations on all 
> platforms.
> +   return 2;
>
> That is dead code, and we can remove it.
> If none of the cases 1, 2 or 3 are true, we will always enter case 4.
That code is there to make sure (in case someone makes changes to that 
function)
that the default return value is 2, since this works for all platforms.

Do you think that leaving a comment is good enough (or not even that)?

>
> Kind Regards,
> Niclas Adlertz
>
> On 05/06/2014 02:43 PM, Albert wrote:
>> Hi all,
>>
>> could I get reviews for this patch?
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>
>> Problem:
>> The minimum number of compiler threads is set incorrectly.
>>
>> Solution:
>> Define a new function 'get_min_number_of_compiler_threads()' that
>> determines the minimum number of compiler threads  for a particular
>> platform/configuration.
>>
>> Testing:
>> Failing test case; zero; -XX:-TieredCompilation -XX:CICompilerCount=1
>>
>> Webrev:
>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>
>> Many thanks in advance,
>> Albert
>>
>>


From niclas.adlertz at oracle.com  Tue May  6 13:25:29 2014
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Tue, 06 May 2014 15:25:29 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <5368E1F4.50308@oracle.com>
References: <5368D8E7.6000800@oracle.com> <5368DDDE.7020908@oracle.com>
	<5368E1F4.50308@oracle.com>
Message-ID: <5368E2C9.9030704@oracle.com>

Hi, see my previous answer. If would suggest to change the nested 
if-else cases to:

// case 1
if (no_compiler) {
   return 0;
}

// case 2 or 3
if (!TieredCompilation || TieredStopAtLevel < CompLevel_full_optimization) {
   return 1;
}

// case 4 (default case, works on all platforms)
return 2

Kind Regards,
Niclas Adlertz

On 05/06/2014 03:21 PM, Albert wrote:
> Hi Niclas,
>
> thanks for looking at this. Please see comment inline.
> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
>> Hi Albert,
>>
>> Inside src/share/vm/runtime/arguments.cpp:
>> +   // We should not come here. However, we also do not fail the VM,
>> since this is a not-critical error.
>> +   assert (false, "Missed configuration to set the minimum number of
>> compiler threads.");
>> +   // Return 2, since this works with all configurations on all
>> platforms.
>> +   return 2;
>>
>> That is dead code, and we can remove it.
>> If none of the cases 1, 2 or 3 are true, we will always enter case 4.
> That code is there to make sure (in case someone makes changes to that
> function)
> that the default return value is 2, since this works for all platforms.
>
> Do you think that leaving a comment is good enough (or not even that)?
>
>>
>> Kind Regards,
>> Niclas Adlertz
>>
>> On 05/06/2014 02:43 PM, Albert wrote:
>>> Hi all,
>>>
>>> could I get reviews for this patch?
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>>
>>> Problem:
>>> The minimum number of compiler threads is set incorrectly.
>>>
>>> Solution:
>>> Define a new function 'get_min_number_of_compiler_threads()' that
>>> determines the minimum number of compiler threads  for a particular
>>> platform/configuration.
>>>
>>> Testing:
>>> Failing test case; zero; -XX:-TieredCompilation -XX:CICompilerCount=1
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>>
>>> Many thanks in advance,
>>> Albert
>>>
>>>
>

From albert.noll at oracle.com  Tue May  6 13:33:34 2014
From: albert.noll at oracle.com (Albert)
Date: Tue, 06 May 2014 15:33:34 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <5368E2C9.9030704@oracle.com>
References: <5368D8E7.6000800@oracle.com> <5368DDDE.7020908@oracle.com>
	<5368E1F4.50308@oracle.com> <5368E2C9.9030704@oracle.com>
Message-ID: <5368E4AE.5020802@oracle.com>

Hi Niclas,

thanks for your suggestions. Your version is much nicer. Here is the 
updated webrev:
http://cr.openjdk.java.net/~anoll/8042431/webrev.01/

Thanks,
Albert

On 05/06/2014 03:25 PM, Niclas Adlertz wrote:
> Hi, see my previous answer. If would suggest to change the nested 
> if-else cases to:
>
> // case 1
> if (no_compiler) {
>   return 0;
> }
>
> // case 2 or 3
> if (!TieredCompilation || TieredStopAtLevel < 
> CompLevel_full_optimization) {
>   return 1;
> }
>
> // case 4 (default case, works on all platforms)
> return 2
>
> Kind Regards,
> Niclas Adlertz
>
> On 05/06/2014 03:21 PM, Albert wrote:
>> Hi Niclas,
>>
>> thanks for looking at this. Please see comment inline.
>> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
>>> Hi Albert,
>>>
>>> Inside src/share/vm/runtime/arguments.cpp:
>>> +   // We should not come here. However, we also do not fail the VM,
>>> since this is a not-critical error.
>>> +   assert (false, "Missed configuration to set the minimum number of
>>> compiler threads.");
>>> +   // Return 2, since this works with all configurations on all
>>> platforms.
>>> +   return 2;
>>>
>>> That is dead code, and we can remove it.
>>> If none of the cases 1, 2 or 3 are true, we will always enter case 4.
>> That code is there to make sure (in case someone makes changes to that
>> function)
>> that the default return value is 2, since this works for all platforms.
>>
>> Do you think that leaving a comment is good enough (or not even that)?
>>
>>>
>>> Kind Regards,
>>> Niclas Adlertz
>>>
>>> On 05/06/2014 02:43 PM, Albert wrote:
>>>> Hi all,
>>>>
>>>> could I get reviews for this patch?
>>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>>>
>>>> Problem:
>>>> The minimum number of compiler threads is set incorrectly.
>>>>
>>>> Solution:
>>>> Define a new function 'get_min_number_of_compiler_threads()' that
>>>> determines the minimum number of compiler threads  for a particular
>>>> platform/configuration.
>>>>
>>>> Testing:
>>>> Failing test case; zero; -XX:-TieredCompilation -XX:CICompilerCount=1
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>>>
>>>> Many thanks in advance,
>>>> Albert
>>>>
>>>>
>>


From igor.veresov at oracle.com  Tue May  6 17:27:29 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 6 May 2014 10:27:29 -0700
Subject: [9] RFR(S): 8029343: CodeCache::allocate increments
	'_number_of_blobs' even if allocation fails.
In-Reply-To: <5368DA63.20107@oracle.com>
References: <53688ECC.5020308@oracle.com>
	<BF34CB10-76ED-4765-8662-1699C588E8B7@oracle.com>
	<5368DA63.20107@oracle.com>
Message-ID: <FA2C69D9-C265-422A-86A9-EB61931291C9@oracle.com>

Alright, sounds like a plan.

igor

On May 6, 2014, at 5:49 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi Igor,
> 
> On 06.05.2014 09:41, Igor Veresov wrote:
>> BufferBlob::operator new() doesn?t seem to be quite ready to see the NULL return. Could we put some error handling in there? Like a call to fatal() similar to other places. Otherwise looks good.
> 
> I would suggest we fix this together with [1]. NULL is already returned in case the allocation in the code cache fails. A call to fatal() is not appropriate here, because the sweeper may solve the problem by freeing space in the code cache.
> 
> Thanks,
> Tobias
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8022968
> 
>> igor
>> 
>> On May 6, 2014, at 12:27 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>> 
>>> Hi,
>>> 
>>> please review the following patch for bug 8029343.
>>> 
>>> Problem:
>>> (1) CodeCache::allocate(...) increments _number_of_blobs before the actual allocation is performed. In case the allocation fails the counter is set to a wrong value.
>>> (2) The guarantee(size >= 0, ...) is incorrect. Calling CodeCache::allocate(...) with size = 0 leads to a segmentation fault. Further, a guarantee is too strong here. We can simply return NULL at runtime if the size is <= 0.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029343
>>> 
>>> Solution:
>>> (1) The increment is moved after the allocation.
>>> (2) An assert is used instead of the guarantee and NULL is returned if size <= 0.
>>> Webrev: http://cr.openjdk.java.net/~anoll/8029343/webrev.00/
>>> 
>>> Thanks,
>>> Tobias
> 


From vladimir.kozlov at oracle.com  Tue May  6 18:07:59 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 06 May 2014 11:07:59 -0700
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <5368E4AE.5020802@oracle.com>
References: <5368D8E7.6000800@oracle.com>
	<5368DDDE.7020908@oracle.com>	<5368E1F4.50308@oracle.com>
	<5368E2C9.9030704@oracle.com> <5368E4AE.5020802@oracle.com>
Message-ID: <536924FF.6080309@oracle.com>

The default for C2 non-tiered should be 2, not 1.

We are mixing 2 things: minimum value and default value. The default is 
CI_COMPILER_COUNT.

Next statement is wrong for ZERO VM:
"A value of 2 works for any platform/configuration."

I don't think we should change globals.hpp, leave it as it is.

We only need to fix the minimum check. The bug is that we used default 
CI_COMPILER_COUNT as minimum value which is wrong.

The fix should be:

+   // Check the minimum number of compiler threads
+   status &=verify_min_value(CICompilerCount, 
get_min_number_of_compiler_threads(), "CICompilerCount");

Note, don't reset the default setting.

You can reduce size of new method more:

+ int Arguments::get_min_number_of_compiler_threads() {
+ #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK)
+   return 0;   // case 1: no compilers (Zero VM)
+ #else
+   if (!TieredCompilation || (TieredStopAtLevel < 
CompLevel_full_optimization)) {
+     return 1; // case 2 or case 3
+   }
+   return 2;   // case 4 (tiered).
+ #endif
+ }

Thanks,
Vladimir

On 5/6/14 6:33 AM, Albert wrote:
> Hi Niclas,
>
> thanks for your suggestions. Your version is much nicer. Here is the
> updated webrev:
> http://cr.openjdk.java.net/~anoll/8042431/webrev.01/
>
> Thanks,
> Albert
>
> On 05/06/2014 03:25 PM, Niclas Adlertz wrote:
>> Hi, see my previous answer. If would suggest to change the nested
>> if-else cases to:
>>
>> // case 1
>> if (no_compiler) {
>>   return 0;
>> }
>>
>> // case 2 or 3
>> if (!TieredCompilation || TieredStopAtLevel <
>> CompLevel_full_optimization) {
>>   return 1;
>> }
>>
>> // case 4 (default case, works on all platforms)
>> return 2
>>
>> Kind Regards,
>> Niclas Adlertz
>>
>> On 05/06/2014 03:21 PM, Albert wrote:
>>> Hi Niclas,
>>>
>>> thanks for looking at this. Please see comment inline.
>>> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
>>>> Hi Albert,
>>>>
>>>> Inside src/share/vm/runtime/arguments.cpp:
>>>> +   // We should not come here. However, we also do not fail the VM,
>>>> since this is a not-critical error.
>>>> +   assert (false, "Missed configuration to set the minimum number of
>>>> compiler threads.");
>>>> +   // Return 2, since this works with all configurations on all
>>>> platforms.
>>>> +   return 2;
>>>>
>>>> That is dead code, and we can remove it.
>>>> If none of the cases 1, 2 or 3 are true, we will always enter case 4.
>>> That code is there to make sure (in case someone makes changes to that
>>> function)
>>> that the default return value is 2, since this works for all platforms.
>>>
>>> Do you think that leaving a comment is good enough (or not even that)?
>>>
>>>>
>>>> Kind Regards,
>>>> Niclas Adlertz
>>>>
>>>> On 05/06/2014 02:43 PM, Albert wrote:
>>>>> Hi all,
>>>>>
>>>>> could I get reviews for this patch?
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>>>>
>>>>> Problem:
>>>>> The minimum number of compiler threads is set incorrectly.
>>>>>
>>>>> Solution:
>>>>> Define a new function 'get_min_number_of_compiler_threads()' that
>>>>> determines the minimum number of compiler threads  for a particular
>>>>> platform/configuration.
>>>>>
>>>>> Testing:
>>>>> Failing test case; zero; -XX:-TieredCompilation -XX:CICompilerCount=1
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>>>>
>>>>> Many thanks in advance,
>>>>> Albert
>>>>>
>>>>>
>>>
>

From vladimir.kozlov at oracle.com  Tue May  6 18:26:30 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 06 May 2014 11:26:30 -0700
Subject: [9] RFR(S): 8029343: CodeCache::allocate increments
	'_number_of_blobs' even if allocation fails.
In-Reply-To: <5368D922.8060600@oracle.com>
References: <53688ECC.5020308@oracle.com> <53689237.9090609@oracle.com>
	<5368D922.8060600@oracle.com>
Message-ID: <53692956.9060208@oracle.com>

On 5/6/14 5:44 AM, Tobias Hartmann wrote:
> Hi Vladimir,
>
> On 06.05.2014 09:41, Vladimir Kozlov wrote:
>> Parfait may complain about returning NULL and without guarantee.
>> Please, test.
>
> I tested the implementation with parfait and no new defects showed up.

Okay.

Thanks,
Vladimir

>
> Thanks,
> Tobias
>
>> Thanks,
>> Vladimir
>>
>> On 5/6/14 12:27 AM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> please review the following patch for bug 8029343.
>>>
>>> *Problem:*
>>> (1) CodeCache::allocate(...) increments _number_of_blobs before the
>>> actual allocation is performed. In case the
>>> allocation fails the counter is set to a wrong value.
>>> (2) The guarantee(size >= 0, ...) is incorrect. Calling
>>> CodeCache::allocate(...) with size = 0 leads to a segmentation
>>> fault. Further, a guarantee is too strong here. We can simply return
>>> NULL at runtime if the size is <= 0.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029343
>>>
>>> *Solution:*
>>> (1) The increment is moved after the allocation.
>>> (2) An assert is used instead of the guarantee and NULL is returned
>>> if size <= 0.
>>> Webrev: http://cr.openjdk.java.net/~anoll/8029343/webrev.00/
>>>
>>> Thanks,
>>> Tobias
>

From john.r.rose at oracle.com  Tue May  6 18:38:48 2014
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 6 May 2014 11:38:48 -0700
Subject: Unsafe for array access
In-Reply-To: <12C1134A-D491-4A59-ACF4-F6E2C10DA112@oracle.com>
References: <12C1134A-D491-4A59-ACF4-F6E2C10DA112@oracle.com>
Message-ID: <A24120D6-D4FA-49C2-8029-D678984260D7@oracle.com>

Paul, this is a reasonable request.  Please file a P3 bug against the hotspot compiler.

Our iteration range splitting transform is gated by a pattern match on a loop body (after inlining).  One of the pattern conditions is that there is an array reference (incl. range check) in the body of the loop.  (Not surprising.)

1. The user-written code should be an alias for a JVM-issued range check.  (The signed/unsigned identities are tricky, and some parts are probably broken.)

2. We should extend our pattern match to allow code like yours to trigger range splitting.

I don't think the above points require deep cuts.

Some background is here:  https://wiki.openjdk.java.net/display/HotSpot/RangeCheckElimination

? John

On May 5, 2014, at 8:20 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
> 
> As part of some investigatory work for JEP 193: Enhanced Volatiles i have been looking at how enhanced (and safe) access to array elements could be implemented.
> 
> The obvious and simple choice is to reach for unsafe with a few safety checks, for example:
> 
>    @ForceInline
>    static void setVolatile(ArrayRefHandle handle, Object[] array, int index,
>            Object value) {
>        if (index < 0 || index >= array.length) // bounds and null check
>            throw new ArrayIndexOutOfBoundsException();
>        UNSAFE.putObjectVolatile(array,
>                                 (((long) index) << handle.ashift) + handle.abase,
>                                 castReference(handle.componentType, value));
>    }
> 
> The problem is the compiler does fully recognize an array access is going on and so certain optimizations tend not to kick in, such as removing or strength reducing bounds checks, or treating "index" as a signed value rather than unsigned.
> 
> Any clues/pointers on how i can hack things so that hotspot knows that an array access is going on in the above code, and views it as almost equivalent to following in terms of optimizations?
> 
>    @ForceInline
>    static void setVolatile(ArrayRefHandle handle, Object[] array, int index,
>            Object value) {
>        if (index < 0 || index >= array.length) // bounds and null check
>            throw new ArrayIndexOutOfBoundsException();
>        array[i] = castReference(handle.componentType, value);
>    }
> 
> 
> Some context: ForkJoinPool is peppered with code like the following:
> 
>                            int i = (((a.length - 1) & b) << ASHIFT) + ABASE;
>                            ForkJoinTask<?> t =
>                                (ForkJoinTask<?>)U.getObjectVolatile(a, i);
> 
> Any viable replacement for direct Unsafe usages in that code will want those strength reducing optimizations to kick in.
> 
> Paul.


From christian.thalinger at oracle.com  Tue May  6 21:27:16 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 6 May 2014 11:27:16 -1000
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
Message-ID: <76D86982-A02D-4545-9D8E-985E53361E55@oracle.com>

src/share/vm/c1/c1_Runtime1.cpp
+   Deoptimization::DeoptReason reason = Deoptimization::trap_request_reason(trap_request);
Unused.

src/share/vm/runtime/sweeper.cpp
+             if (time_since_reset > MinPassesBeforeFlush * 2) {
Why is it *2?

On May 5, 2014, at 4:44 PM, Igor Veresov <igor.veresov at oracle.com> wrote:

> The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows:
> 
> 1. Initially a method is compiled as usual (no instrumentation, no overhead).
> 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code.
> 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter.
> 4. The value of the counter is then used by the sweeper to determine is the method is in fact used.
> 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again. 
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
> 
> Testing: 
> - jprt,
> - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations.
> 
> igor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140506/2d3257b7/attachment.html>

From christian.thalinger at oracle.com  Tue May  6 21:28:27 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 6 May 2014 11:28:27 -1000
Subject: RFR(XS) 8041415: remove port.{cpp,hpp} files
In-Reply-To: <5368D9F1.3010306@oracle.com>
References: <5367F2D5.4080606@oracle.com> <5367F65A.6090906@oracle.com>
	<5368D9F1.3010306@oracle.com>
Message-ID: <B5080363-81F8-4763-B5C4-AA1FC6CEEE5A@oracle.com>

You don?t have to withdraw the request just push it after Lois? changes are in.

On May 6, 2014, at 2:47 AM, Zhengyu Gu <zhengyu.gu at oracle.com> wrote:

> Vladimir,
> 
> Thanks for pointing out.
> 
> At this point, I would like to withdraw this request, and will resubmit it after Lois' changes get in.
> 
> -Zhengyu
> 
> 
> On 5/5/2014 4:36 PM, Vladimir Kozlov wrote:
>> CC to compiler alias since you changing our code.
>> 
>> Copyright year change should be 2014.
>> 
>> FileBuffRegion removal is done under separate bug 8041620 by Lois Foltan, the review was sent today today.
>> 
>> domgraph.cpp, output.cpp: use max_juint instead of (uint) -1.
>> 
>> Thanks,
>> Vladimir
>> 
>> On 5/5/14 1:21 PM, Zhengyu Gu wrote:
>>> This is a code cleanup based on attached patch from Christian Thalinger.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8041415
>>> Webrev:
>> 
>> http://cr.openjdk.java.net/~zgu/8041415/webrev.00/
>> 
>>> 
>>> Test:
>>>   JPRT
>>> 
>>> Thanks,
>>> 
> 


From igor.veresov at oracle.com  Tue May  6 22:11:05 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 6 May 2014 15:11:05 -0700
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <76D86982-A02D-4545-9D8E-985E53361E55@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
	<76D86982-A02D-4545-9D8E-985E53361E55@oracle.com>
Message-ID: <881A80A6-4BA1-4A2F-BC1E-8B565D5BA79E@oracle.com>


On May 6, 2014, at 2:27 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> src/share/vm/c1/c1_Runtime1.cpp
> +   Deoptimization::DeoptReason reason = Deoptimization::trap_request_reason(trap_request);
> Unused.

Alright, I?ll remove it.

> 
> src/share/vm/runtime/sweeper.cpp
> +             if (time_since_reset > MinPassesBeforeFlush * 2) {
> Why is it *2?


I figured it would be fair to give it another 10 passes after we noticed it changed behavior (when we?re at this point time_size_reset is already > MinPassesBeforeFlush) to introduce some hysteresis that would quell possible oscillations.

igor



> 
> On May 5, 2014, at 4:44 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
>> The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows:
>> 
>> 1. Initially a method is compiled as usual (no instrumentation, no overhead).
>> 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code.
>> 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter.
>> 4. The value of the counter is then used by the sweeper to determine is the method is in fact used.
>> 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again. 
>> 
>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>> 
>> Testing: 
>> - jprt,
>> - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations.
>> 
>> igor
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140506/d958eaf3/attachment-0001.html>

From vladimir.kozlov at oracle.com  Wed May  7 00:05:36 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 06 May 2014 17:05:36 -0700
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
Message-ID: <536978D0.7060901@oracle.com>

I think we need to let SAP know about this change (counter code in C2) 
since it may affect their tiered compilation. It use the same 
Deoptimization::Reason_age.

Can you separate C1 trap_request newa code in a separate RFE and push it 
first?

Can you add the field to MDO and not to MethodCounters? We doing this 
only for methods which were compiled already and have MDO. 
MethodCounters small size is important.

Can you use Method* method instead of next expression?:

MethodCounters::should_nmethod_age(method()->nmethod_age())

like: method()->should_nmethod_age().

Also the name is not good, I think. How about profile_aging()?

Rename Parse::decrement_code_age() --> Parse::decrement_age().

Add comment to _age_code in compile.hpp

Why the change in methodData.hpp and nmethod.cpp? '||' should be '&&' in 
nmethod::inc_decompile_count(), I think.

In globals.hpp flags description indention is off.

sweeper.cpp:

// The stack-scanning low-cost detection may not see the method was used 
(which can happen for

// previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in the 
existing

Why do you need to repeat? For small leaf nmethods (with no safepoint, 
for example) it could trigger continues recompilation:

+             if (time_since_reset > MinPassesBeforeFlush * 2) {
+               // It's been long enough, we still haven't seen it on stack.
+               // Try to flush it, but enable counters the next time.
+               mc->reset_nmethod_age();

Thanks,
Vladimir

On 5/5/14 7:44 PM, Igor Veresov wrote:
> The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows:
>
> 1. Initially a method is compiled as usual (no instrumentation, no overhead).
> 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code.
> 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter.
> 4. The value of the counter is then used by the sweeper to determine is the method is in fact used.
> 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again.
>
> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>
> Testing:
> - jprt,
> - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations.
>
> igor
>

From igor.veresov at oracle.com  Wed May  7 07:37:18 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 7 May 2014 00:37:18 -0700
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <536978D0.7060901@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
	<536978D0.7060901@oracle.com>
Message-ID: <3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com>

Vladimir,

Thanks for the review!
Please find the reply inline.

igor

On May 6, 2014, at 5:05 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> I think we need to let SAP know about this change (counter code in C2) since it may affect their tiered compilation. It use the same Deoptimization::Reason_age.
> 
Oh, I didn?t know that. I?ll introduce another constant.

> Can you separate C1 trap_request newa code in a separate RFE and push it first?
> 

Do you think this is necessary? It so happens that the DeoptimizeStub was not used before this by any code. So the aging scheme is the only user of it so far.

> Can you add the field to MDO and not to MethodCounters? We doing this only for methods which were compiled already and have MDO. MethodCounters small size is important.

It was in MDO originally, unfortunately I have to make it work for pure C1 and we usually don?t allocate MDOs in that configuration. Although, we need to only allocate MDOs for methods with aging, a set of which may be would be smallish..  But MDOs are kind of big.. Would that be better?

> 
> Can you use Method* method instead of next expression?:
> 
> MethodCounters::should_nmethod_age(method()->nmethod_age())
> 
> like: method()->should_nmethod_age().
> 
> Also the name is not good, I think. How about profile_aging()?

Ok, I?ll add this.

> 
> Rename Parse::decrement_code_age() --> Parse::decrement_age().

Ok

> 
> Add comment to _age_code in compile.hpp
> 

Ok

> Why the change in methodData.hpp and nmethod.cpp? '||' should be '&&' in nmethod::inc_decompile_count(), I think.

You?re right, for pure C1 that won?t work anyways, because there are no MDOs. I?ll remove these for now. I probably need another decompile counter to put a cap on the number of recompiles, see the idea below.

> In globals.hpp flags description indention is off.
> 

Fixed.

> sweeper.cpp:
> 
> // The stack-scanning low-cost detection may not see the method was used (which can happen for
> 
> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in the existing
> 
> Why do you need to repeat? For small leaf nmethods (with no safepoint, for example) it could trigger continues recompilation:
> 
> +             if (time_since_reset > MinPassesBeforeFlush * 2) {
> +               // It's been long enough, we still haven't seen it on stack.
> +               // Try to flush it, but enable counters the next time.
> +               mc->reset_nmethod_age();
> 

That?s a good question. Before this change we would?ve recompiled warm methods continuously (given some code cache pressure), so the number of such cases is probably small. The options here with the code aging are: 
- don?t ever again flush a method that we?ve seen deopt once;
- allow the flusher machinery to get rid of it if it becomes idle again.

Currently I decided to stick with the latter but also give the method twice the standard time initially to be noticed by the stack-walker. You are right that there is a problem for small methods. Technically there is always one safepoint in the epilog though, right? I?m good with either option. Vladimir, what are your thoughts on this? Albert, if you skimming through this, what do you think?

Here is an idea... We could count the number of decompiles for this particular reason and use it to scale the number of stack-walks we have to do before we flush the method again. For example we can wait MinPassesBeforeFlush * number_of_aging_deopts() stack-walks. Essentially this makes it unflushable in the limit - a combination of the two options above.
I?ll need to allocate an MDO or add another counter to methodCounters for that though, or pack a small value info method_age itself, at the expense of a slightly bigger code. And there is an MT problem, as usual, with counting the number of deopts.

Here is the updated (with the changes addressed so far) webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/

Thanks,
igor

> Thanks,
> Vladimir
> 
> On 5/5/14 7:44 PM, Igor Veresov wrote:
>> The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows:
>> 
>> 1. Initially a method is compiled as usual (no instrumentation, no overhead).
>> 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code.
>> 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter.
>> 4. The value of the counter is then used by the sweeper to determine is the method is in fact used.
>> 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again.
>> 
>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>> 
>> Testing:
>> - jprt,
>> - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations.
>> 
>> igor
>> 


From dl at cs.oswego.edu  Wed May  7 11:30:04 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 07 May 2014 07:30:04 -0400
Subject: Unsafe for array access
In-Reply-To: <12C1134A-D491-4A59-ACF4-F6E2C10DA112@oracle.com>
References: <12C1134A-D491-4A59-ACF4-F6E2C10DA112@oracle.com>
Message-ID: <536A193C.7020405@cs.oswego.edu>

On 05/05/2014 11:20 AM, Paul Sandoz wrote:
> Hi,
>
> As part of some investigatory work for JEP 193: Enhanced Volatiles i have been looking at how enhanced (and safe) access to array elements could be implemented.
>
> The obvious and simple choice is to reach for unsafe with a few safety checks, for example:
>
>      @ForceInline
>      static void setVolatile(ArrayRefHandle handle, Object[] array, int index,
>              Object value) {
>          if (index < 0 || index >= array.length) // bounds and null check
>              throw new ArrayIndexOutOfBoundsException();
>          UNSAFE.putObjectVolatile(array,
>                                   (((long) index) << handle.ashift) + handle.abase,
>                                   castReference(handle.componentType, value));
>      }
>

Relatedly, it might be be nice to have an intrinsic boundsCheck(array, index)
that could be used in such cases that implemented using the more efficient
(using C): (unsigned)index >= (unsigned)array.length, plus relied on more
efficient VM throw mechanics on failure.

>
> Some context: ForkJoinPool is peppered with code like the following:
>
>                              int i = (((a.length - 1) & b) << ASHIFT) + ABASE;
>                              ForkJoinTask<?> t =
>                                  (ForkJoinTask<?>)U.getObjectVolatile(a, i);
>
> Any viable replacement for direct Unsafe usages in that code will want those strength reducing optimizations to kick in.
>

Similarly for ConcurrentHashMap. It's hard to say how typical
this style of use is outside of these two classes though. The need to
use Unsafe array access impacted overall class design. To maintain
a proper level of paranoia about using Unsafe, arrays are always
powers of two, indexes use masks and explicit int (not long) shifts
guaranteed so that offsets cannot escape bounds unless array lengths
are zero or >= than 1<<(31-sizeof(pointer)). Construction is
isolated to make it easily statically checkable (in principal)
that lengths are OK.

(Also, in FJ, these constructions are not often used in loops, so
loop optimizations will have less impact than just streamlining
get/put/cas, which are the main operations in fork() and work-stealing,
so slowdowns will have measurable impact.)

-Doug


From bertrand.delsart at oracle.com  Wed May  7 11:56:29 2014
From: bertrand.delsart at oracle.com (Bertrand Delsart)
Date: Wed, 07 May 2014 13:56:29 +0200
Subject: RFR(S): 8031475: Missing oopmap in patching stubs
In-Reply-To: <5360F539.9090408@oracle.com>
References: <5360F539.9090408@oracle.com>
Message-ID: <536A1F6D.8090501@oracle.com>

On 30/04/14 15:06, Nils Eliasson wrote:
> Hi,
>
> I would like some feedback on this change from the c1 experts. It's made
> in platform dependent code and will be added to the other plattforms as
> well before submit.
>
> This change fixes a bug that has been observed in testing, and dug up
> from a core file, but haven't reproduced standalone yet. When patching
> for checkcast the oop we are casting is not kept in an oopmap during the
> runtime patching call, a one time chance per run.
>
> The current change is for all the patching stub cases (access_field_id,
> load_klass_id, load_mirror_id, load_appendix_id) - is that needed? Do
> you see any potential for breaking anything? It is difficult to trigger
> a GC at exact this point during a test.

It is not needed for all patching operations and might be dangerous. You 
should add _obj to the oopMap only if you are sure _obj is an oop.

In most cases, these oops are input arguments of the C1 instruction and 
should have been added to the patching info before calling 
PatchingStub::emit_code.

Problems mostly occur when loading such an oop in a temporary register 
(like here to check for NULL) before potentially calling some patching 
code. In that case, you can either:
- fix 'info' in the code that calls the patching stub generator (e.g. 
the caller is responsible for ensuring the value in the temporary 
register is protected)
- or ignore the value in the temporary register when patching occurred 
(e.g. reload the oop after the runtime patching call).

This would be cleaner than hard coding in the patching stub that for 
some patching_ids, _obj is an oop that is not yet covered by an oopmap.

>
> http://cr.openjdk.java.net/~neliasso/8031475/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8031475
>
> Thanks,
> Nils Eliasson
>
>
> Code example:
>
>    0x00007f20c943590c: mov    $0x718d65d38,%rdx  ;   {oop(a
> 'BeanImpl2')}   // oops to be casted in rdx
>    0x00007f20c9435916: cmp    $0x0,%rdx
>    0x00007f20c943591a: je     0x00007f20c9435967   // jump to patching stub
>    // patch location
>    0x00007f20c9435920: jmpq   0x00007f20c94359c5  ;   {no_reloc}
>    0x00007f20c9435925: add    %al,(%rax)
>    0x00007f20c9435927: add    %al,(%rax)
>    0x00007f20c9435929: add    %cl,-0x3eb7f786(%rbx)
>    0x00007f20c943592f: out    %eax,$0x3
>    // end of patch location
>    0x00007f20c9435931: cmp    %rbx,%rdi
>    0x00007f20c9435934: je     0x00007f20c9435967 // A dereference of rdx
> somewhere here may crash if the oop has moved during a gc
>    0x00007f20c943593a: mov    0x10(%rbx),%esi
>    0x00007f20c943593d: cmp    (%rdi,%rsi,1),%rbx
>    0x00007f20c9435941: je     0x00007f20c9435967
>
>    ...
>
>    ;; PatchingStub slow case
>    ;;  patch template
>    0x00007f20c94359b6: mov    $0x0,%rbx          ;   {metadata(NULL)}
>    ;; patch data encoded as movl
>    0x00007f20c94359c0: mov    $0xa050f00,%eax
>    ;; patch entry point
>    0x00007f20c94359c5: callq  0x00007f20c942e3e0  ; OopMap{[32]=Oop
> off=266}   // rdx not live here, may safepoint on return from runtime call
>                                                  ;*checkcast
>                                                  ; -
> TestCheckCast::main at 25 (line 24)
>                                                  ;   {runtime_call}
>    0x00007f20c94359ca: jmpq   0x00007f20c9435920   // back to normal
> control flow after patching
>


-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38334 Saint Ismier,                                        FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From albert.noll at oracle.com  Wed May  7 15:08:51 2014
From: albert.noll at oracle.com (Albert)
Date: Wed, 07 May 2014 17:08:51 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <536924FF.6080309@oracle.com>
References: <5368D8E7.6000800@oracle.com>	<5368DDDE.7020908@oracle.com>	<5368E1F4.50308@oracle.com>	<5368E2C9.9030704@oracle.com>
	<5368E4AE.5020802@oracle.com> <536924FF.6080309@oracle.com>
Message-ID: <536A4C83.4030805@oracle.com>

Hi Vladimir,

thanks for looking at this. I followed your suggestions and adapted the 
webrev accordingly.
Here is the new version:
http://cr.openjdk.java.net/~anoll/8042431/webrev.02/

Best,
Albert

On 05/06/2014 08:07 PM, Vladimir Kozlov wrote:
> The default for C2 non-tiered should be 2, not 1.
>
> We are mixing 2 things: minimum value and default value. The default 
> is CI_COMPILER_COUNT.
>
> Next statement is wrong for ZERO VM:
> "A value of 2 works for any platform/configuration."
>
> I don't think we should change globals.hpp, leave it as it is.
>
> We only need to fix the minimum check. The bug is that we used default 
> CI_COMPILER_COUNT as minimum value which is wrong.
>
> The fix should be:
>
> +   // Check the minimum number of compiler threads
> +   status &=verify_min_value(CICompilerCount, 
> get_min_number_of_compiler_threads(), "CICompilerCount");
>
> Note, don't reset the default setting.
>
> You can reduce size of new method more:
>
> + int Arguments::get_min_number_of_compiler_threads() {
> + #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK)
> +   return 0;   // case 1: no compilers (Zero VM)
> + #else
> +   if (!TieredCompilation || (TieredStopAtLevel < 
> CompLevel_full_optimization)) {
> +     return 1; // case 2 or case 3
> +   }
> +   return 2;   // case 4 (tiered).
> + #endif
> + }
>
> Thanks,
> Vladimir
>
> On 5/6/14 6:33 AM, Albert wrote:
>> Hi Niclas,
>>
>> thanks for your suggestions. Your version is much nicer. Here is the
>> updated webrev:
>> http://cr.openjdk.java.net/~anoll/8042431/webrev.01/
>>
>> Thanks,
>> Albert
>>
>> On 05/06/2014 03:25 PM, Niclas Adlertz wrote:
>>> Hi, see my previous answer. If would suggest to change the nested
>>> if-else cases to:
>>>
>>> // case 1
>>> if (no_compiler) {
>>>   return 0;
>>> }
>>>
>>> // case 2 or 3
>>> if (!TieredCompilation || TieredStopAtLevel <
>>> CompLevel_full_optimization) {
>>>   return 1;
>>> }
>>>
>>> // case 4 (default case, works on all platforms)
>>> return 2
>>>
>>> Kind Regards,
>>> Niclas Adlertz
>>>
>>> On 05/06/2014 03:21 PM, Albert wrote:
>>>> Hi Niclas,
>>>>
>>>> thanks for looking at this. Please see comment inline.
>>>> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
>>>>> Hi Albert,
>>>>>
>>>>> Inside src/share/vm/runtime/arguments.cpp:
>>>>> +   // We should not come here. However, we also do not fail the VM,
>>>>> since this is a not-critical error.
>>>>> +   assert (false, "Missed configuration to set the minimum number of
>>>>> compiler threads.");
>>>>> +   // Return 2, since this works with all configurations on all
>>>>> platforms.
>>>>> +   return 2;
>>>>>
>>>>> That is dead code, and we can remove it.
>>>>> If none of the cases 1, 2 or 3 are true, we will always enter case 4.
>>>> That code is there to make sure (in case someone makes changes to that
>>>> function)
>>>> that the default return value is 2, since this works for all 
>>>> platforms.
>>>>
>>>> Do you think that leaving a comment is good enough (or not even that)?
>>>>
>>>>>
>>>>> Kind Regards,
>>>>> Niclas Adlertz
>>>>>
>>>>> On 05/06/2014 02:43 PM, Albert wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> could I get reviews for this patch?
>>>>>>
>>>>>> Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>>>>>
>>>>>> Problem:
>>>>>> The minimum number of compiler threads is set incorrectly.
>>>>>>
>>>>>> Solution:
>>>>>> Define a new function 'get_min_number_of_compiler_threads()' that
>>>>>> determines the minimum number of compiler threads  for a particular
>>>>>> platform/configuration.
>>>>>>
>>>>>> Testing:
>>>>>> Failing test case; zero; -XX:-TieredCompilation 
>>>>>> -XX:CICompilerCount=1
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>>>>>
>>>>>> Many thanks in advance,
>>>>>> Albert
>>>>>>
>>>>>>
>>>>
>>


From john.r.rose at oracle.com  Wed May  7 15:56:19 2014
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 7 May 2014 08:56:19 -0700
Subject: Unsafe for array access
In-Reply-To: <536A193C.7020405@cs.oswego.edu>
References: <12C1134A-D491-4A59-ACF4-F6E2C10DA112@oracle.com>
	<536A193C.7020405@cs.oswego.edu>
Message-ID: <F5A5CA0F-DCA2-4CDD-8B2D-48F193717C53@oracle.com>

> On May 7, 2014, at 4:30 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> 
> Relatedly, it might be be nice to have an intrinsic boundsCheck(array, index)
> that could be used in such cases that implemented using the more efficient
> (using C): (unsigned)index >= (unsigned)array.length, plus relied on more
> efficient VM throw mechanics on failure.

We need an intrinsic like this for Arrays 2.0. Might as well do it now, since we have an immediate application. 

Counterpoint:  optimizer can and should generate similar code for plain user written range tests. 

Advice:  Do both, and the intrinsic will give everybody a clearer target to aim for. Unit test the intrinsic optimization, and several similar formulations. 

? John

From vladimir.kozlov at oracle.com  Wed May  7 16:04:42 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 07 May 2014 09:04:42 -0700
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <536A4C83.4030805@oracle.com>
References: <5368D8E7.6000800@oracle.com>	<5368DDDE.7020908@oracle.com>	<5368E1F4.50308@oracle.com>	<5368E2C9.9030704@oracle.com>	<5368E4AE.5020802@oracle.com>
	<536924FF.6080309@oracle.com> <536A4C83.4030805@oracle.com>
Message-ID: <536A599A.4070905@oracle.com>

Good.

Thanks,
Vladimir

On 5/7/14 8:08 AM, Albert wrote:
> Hi Vladimir,
>
> thanks for looking at this. I followed your suggestions and adapted the webrev accordingly.
> Here is the new version:
> http://cr.openjdk.java.net/~anoll/8042431/webrev.02/
>
> Best,
> Albert
>
> On 05/06/2014 08:07 PM, Vladimir Kozlov wrote:
>> The default for C2 non-tiered should be 2, not 1.
>>
>> We are mixing 2 things: minimum value and default value. The default is CI_COMPILER_COUNT.
>>
>> Next statement is wrong for ZERO VM:
>> "A value of 2 works for any platform/configuration."
>>
>> I don't think we should change globals.hpp, leave it as it is.
>>
>> We only need to fix the minimum check. The bug is that we used default CI_COMPILER_COUNT as minimum value which is wrong.
>>
>> The fix should be:
>>
>> +   // Check the minimum number of compiler threads
>> +   status &=verify_min_value(CICompilerCount, get_min_number_of_compiler_threads(), "CICompilerCount");
>>
>> Note, don't reset the default setting.
>>
>> You can reduce size of new method more:
>>
>> + int Arguments::get_min_number_of_compiler_threads() {
>> + #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK)
>> +   return 0;   // case 1: no compilers (Zero VM)
>> + #else
>> +   if (!TieredCompilation || (TieredStopAtLevel < CompLevel_full_optimization)) {
>> +     return 1; // case 2 or case 3
>> +   }
>> +   return 2;   // case 4 (tiered).
>> + #endif
>> + }
>>
>> Thanks,
>> Vladimir
>>
>> On 5/6/14 6:33 AM, Albert wrote:
>>> Hi Niclas,
>>>
>>> thanks for your suggestions. Your version is much nicer. Here is the
>>> updated webrev:
>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.01/
>>>
>>> Thanks,
>>> Albert
>>>
>>> On 05/06/2014 03:25 PM, Niclas Adlertz wrote:
>>>> Hi, see my previous answer. If would suggest to change the nested
>>>> if-else cases to:
>>>>
>>>> // case 1
>>>> if (no_compiler) {
>>>>   return 0;
>>>> }
>>>>
>>>> // case 2 or 3
>>>> if (!TieredCompilation || TieredStopAtLevel <
>>>> CompLevel_full_optimization) {
>>>>   return 1;
>>>> }
>>>>
>>>> // case 4 (default case, works on all platforms)
>>>> return 2
>>>>
>>>> Kind Regards,
>>>> Niclas Adlertz
>>>>
>>>> On 05/06/2014 03:21 PM, Albert wrote:
>>>>> Hi Niclas,
>>>>>
>>>>> thanks for looking at this. Please see comment inline.
>>>>> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
>>>>>> Hi Albert,
>>>>>>
>>>>>> Inside src/share/vm/runtime/arguments.cpp:
>>>>>> +   // We should not come here. However, we also do not fail the VM,
>>>>>> since this is a not-critical error.
>>>>>> +   assert (false, "Missed configuration to set the minimum number of
>>>>>> compiler threads.");
>>>>>> +   // Return 2, since this works with all configurations on all
>>>>>> platforms.
>>>>>> +   return 2;
>>>>>>
>>>>>> That is dead code, and we can remove it.
>>>>>> If none of the cases 1, 2 or 3 are true, we will always enter case 4.
>>>>> That code is there to make sure (in case someone makes changes to that
>>>>> function)
>>>>> that the default return value is 2, since this works for all platforms.
>>>>>
>>>>> Do you think that leaving a comment is good enough (or not even that)?
>>>>>
>>>>>>
>>>>>> Kind Regards,
>>>>>> Niclas Adlertz
>>>>>>
>>>>>> On 05/06/2014 02:43 PM, Albert wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> could I get reviews for this patch?
>>>>>>>
>>>>>>> Bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>>>>>>
>>>>>>> Problem:
>>>>>>> The minimum number of compiler threads is set incorrectly.
>>>>>>>
>>>>>>> Solution:
>>>>>>> Define a new function 'get_min_number_of_compiler_threads()' that
>>>>>>> determines the minimum number of compiler threads  for a particular
>>>>>>> platform/configuration.
>>>>>>>
>>>>>>> Testing:
>>>>>>> Failing test case; zero; -XX:-TieredCompilation -XX:CICompilerCount=1
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>>>>>>
>>>>>>> Many thanks in advance,
>>>>>>> Albert
>>>>>>>
>>>>>>>
>>>>>
>>>
>

From vladimir.kozlov at oracle.com  Wed May  7 16:15:59 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 07 May 2014 09:15:59 -0700
Subject: Unsafe for array access
In-Reply-To: <F5A5CA0F-DCA2-4CDD-8B2D-48F193717C53@oracle.com>
References: <12C1134A-D491-4A59-ACF4-F6E2C10DA112@oracle.com>	<536A193C.7020405@cs.oswego.edu>
	<F5A5CA0F-DCA2-4CDD-8B2D-48F193717C53@oracle.com>
Message-ID: <536A5C3F.1070005@oracle.com>

Note, we do convert some user's bound check to array's range check. The example is Integer::valueOf():

     public static Integer valueOf(int i) {
         if (i >= IntegerCache.low && i <= IntegerCache.high)
             return IntegerCache.cache[i + (-IntegerCache.low)];
         return new Integer(i);
     }

The check is converted to ((i-IntegerCache.low) u< IntegerCache.length) and removed as duplicate of the generated range 
check for the following load.

length = (high - low) + 1

Vladimir

On 5/7/14 8:56 AM, John Rose wrote:
>> On May 7, 2014, at 4:30 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>
>>
>> Relatedly, it might be be nice to have an intrinsic boundsCheck(array, index)
>> that could be used in such cases that implemented using the more efficient
>> (using C): (unsigned)index >= (unsigned)array.length, plus relied on more
>> efficient VM throw mechanics on failure.
>
> We need an intrinsic like this for Arrays 2.0. Might as well do it now, since we have an immediate application.
>
> Counterpoint:  optimizer can and should generate similar code for plain user written range tests.
>
> Advice:  Do both, and the intrinsic will give everybody a clearer target to aim for. Unit test the intrinsic optimization, and several similar formulations.
>
> ? John
>

From vladimir.kozlov at oracle.com  Wed May  7 17:08:54 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 07 May 2014 10:08:54 -0700
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <536A599A.4070905@oracle.com>
References: <5368D8E7.6000800@oracle.com>	<5368DDDE.7020908@oracle.com>	<5368E1F4.50308@oracle.com>	<5368E2C9.9030704@oracle.com>	<5368E4AE.5020802@oracle.com>	<536924FF.6080309@oracle.com>
	<536A4C83.4030805@oracle.com> <536A599A.4070905@oracle.com>
Message-ID: <536A68A6.4090104@oracle.com>

I just saw Severin's comment.

The check we have already verifies that minimum <= CI_COMPILER_COUNT when CICompilerCount is not specified on command 
line. But to have explicit assert is better, I think:

   int min_number_of_compiler_threads = get_min_number_of_compiler_threads();
   // The default CICompilerCount's value is CI_COMPILER_COUNT.
   assert(min_number_of_compiler_threads <= CI_COMPILER_COUNT, "minimum should be less or equal default number");
   // Check the minimum number of compiler threads.
   status &=verify_min_value(CICompilerCount, min_number_of_compiler_threads, "CICompilerCount");

Thanks,
Vladimir

On 5/7/14 9:04 AM, Vladimir Kozlov wrote:
> Good.
>
> Thanks,
> Vladimir
>
> On 5/7/14 8:08 AM, Albert wrote:
>> Hi Vladimir,
>>
>> thanks for looking at this. I followed your suggestions and adapted the webrev accordingly.
>> Here is the new version:
>> http://cr.openjdk.java.net/~anoll/8042431/webrev.02/
>>
>> Best,
>> Albert
>>
>> On 05/06/2014 08:07 PM, Vladimir Kozlov wrote:
>>> The default for C2 non-tiered should be 2, not 1.
>>>
>>> We are mixing 2 things: minimum value and default value. The default is CI_COMPILER_COUNT.
>>>
>>> Next statement is wrong for ZERO VM:
>>> "A value of 2 works for any platform/configuration."
>>>
>>> I don't think we should change globals.hpp, leave it as it is.
>>>
>>> We only need to fix the minimum check. The bug is that we used default CI_COMPILER_COUNT as minimum value which is
>>> wrong.
>>>
>>> The fix should be:
>>>
>>> +   // Check the minimum number of compiler threads
>>> +   status &=verify_min_value(CICompilerCount, get_min_number_of_compiler_threads(), "CICompilerCount");
>>>
>>> Note, don't reset the default setting.
>>>
>>> You can reduce size of new method more:
>>>
>>> + int Arguments::get_min_number_of_compiler_threads() {
>>> + #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK)
>>> +   return 0;   // case 1: no compilers (Zero VM)
>>> + #else
>>> +   if (!TieredCompilation || (TieredStopAtLevel < CompLevel_full_optimization)) {
>>> +     return 1; // case 2 or case 3
>>> +   }
>>> +   return 2;   // case 4 (tiered).
>>> + #endif
>>> + }
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/6/14 6:33 AM, Albert wrote:
>>>> Hi Niclas,
>>>>
>>>> thanks for your suggestions. Your version is much nicer. Here is the
>>>> updated webrev:
>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.01/
>>>>
>>>> Thanks,
>>>> Albert
>>>>
>>>> On 05/06/2014 03:25 PM, Niclas Adlertz wrote:
>>>>> Hi, see my previous answer. If would suggest to change the nested
>>>>> if-else cases to:
>>>>>
>>>>> // case 1
>>>>> if (no_compiler) {
>>>>>   return 0;
>>>>> }
>>>>>
>>>>> // case 2 or 3
>>>>> if (!TieredCompilation || TieredStopAtLevel <
>>>>> CompLevel_full_optimization) {
>>>>>   return 1;
>>>>> }
>>>>>
>>>>> // case 4 (default case, works on all platforms)
>>>>> return 2
>>>>>
>>>>> Kind Regards,
>>>>> Niclas Adlertz
>>>>>
>>>>> On 05/06/2014 03:21 PM, Albert wrote:
>>>>>> Hi Niclas,
>>>>>>
>>>>>> thanks for looking at this. Please see comment inline.
>>>>>> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
>>>>>>> Hi Albert,
>>>>>>>
>>>>>>> Inside src/share/vm/runtime/arguments.cpp:
>>>>>>> +   // We should not come here. However, we also do not fail the VM,
>>>>>>> since this is a not-critical error.
>>>>>>> +   assert (false, "Missed configuration to set the minimum number of
>>>>>>> compiler threads.");
>>>>>>> +   // Return 2, since this works with all configurations on all
>>>>>>> platforms.
>>>>>>> +   return 2;
>>>>>>>
>>>>>>> That is dead code, and we can remove it.
>>>>>>> If none of the cases 1, 2 or 3 are true, we will always enter case 4.
>>>>>> That code is there to make sure (in case someone makes changes to that
>>>>>> function)
>>>>>> that the default return value is 2, since this works for all platforms.
>>>>>>
>>>>>> Do you think that leaving a comment is good enough (or not even that)?
>>>>>>
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>> Niclas Adlertz
>>>>>>>
>>>>>>> On 05/06/2014 02:43 PM, Albert wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> could I get reviews for this patch?
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>>>>>>>
>>>>>>>> Problem:
>>>>>>>> The minimum number of compiler threads is set incorrectly.
>>>>>>>>
>>>>>>>> Solution:
>>>>>>>> Define a new function 'get_min_number_of_compiler_threads()' that
>>>>>>>> determines the minimum number of compiler threads  for a particular
>>>>>>>> platform/configuration.
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> Failing test case; zero; -XX:-TieredCompilation -XX:CICompilerCount=1
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>>>>>>>
>>>>>>>> Many thanks in advance,
>>>>>>>> Albert
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>

From david.r.chase at oracle.com  Wed May  7 17:23:58 2014
From: david.r.chase at oracle.com (David Chase)
Date: Wed, 7 May 2014 13:23:58 -0400
Subject: Unsafe for array access
In-Reply-To: <F5A5CA0F-DCA2-4CDD-8B2D-48F193717C53@oracle.com>
References: <12C1134A-D491-4A59-ACF4-F6E2C10DA112@oracle.com>
	<536A193C.7020405@cs.oswego.edu>
	<F5A5CA0F-DCA2-4CDD-8B2D-48F193717C53@oracle.com>
Message-ID: <D05EF33C-5279-4F1C-8DF1-48C770160D98@oracle.com>

Don't we now have an Unsigned class providing these operations? (which could be intrinsified)
Or did we want to tie the intrinsic more closely to array classes?

David

On 2014-05-07, at 11:56 AM, John Rose <john.r.rose at oracle.com> wrote:

>> On May 7, 2014, at 4:30 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
>> 
>> Relatedly, it might be be nice to have an intrinsic boundsCheck(array, index)
>> that could be used in such cases that implemented using the more efficient
>> (using C): (unsigned)index >= (unsigned)array.length, plus relied on more
>> efficient VM throw mechanics on failure.
> 
> We need an intrinsic like this for Arrays 2.0. Might as well do it now, since we have an immediate application. 
> 
> Counterpoint:  optimizer can and should generate similar code for plain user written range tests. 
> 
> Advice:  Do both, and the intrinsic will give everybody a clearer target to aim for. Unit test the intrinsic optimization, and several similar formulations. 
> 
> ? John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140507/679d687e/signature.asc>

From john.r.rose at oracle.com  Wed May  7 18:03:08 2014
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 7 May 2014 11:03:08 -0700
Subject: Unsafe for array access
In-Reply-To: <D05EF33C-5279-4F1C-8DF1-48C770160D98@oracle.com>
References: <12C1134A-D491-4A59-ACF4-F6E2C10DA112@oracle.com>
	<536A193C.7020405@cs.oswego.edu>
	<F5A5CA0F-DCA2-4CDD-8B2D-48F193717C53@oracle.com>
	<D05EF33C-5279-4F1C-8DF1-48C770160D98@oracle.com>
Message-ID: <422BA92D-386C-48BC-87EC-4F3441F62EF3@oracle.com>

On May 7, 2014, at 10:23 AM, David Chase <david.r.chase at oracle.com> wrote:

> Don't we now have an Unsigned class providing these operations? (which could be intrinsified)
> Or did we want to tie the intrinsic more closely to array classes?

It's not a class.  (Some day a value type!)  We have the method Integer.compareUnsigned, which should not even need intrinsifying, but may need a little pattern matching help in GVN.

Doug is suggesting (and I concur) that it would be good to package up both the test and the error path, or at least have a test method that the optimizer can treat as a never failing test.

In whatever form, the test should play nicely with range check elimination, and (probably) also with any optimistic range check related conditions, such as are found in deoptimization.hpp.

? John

> David
> 
> On 2014-05-07, at 11:56 AM, John Rose <john.r.rose at oracle.com> wrote:
> 
>>> On May 7, 2014, at 4:30 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>> 
>>> 
>>> Relatedly, it might be be nice to have an intrinsic boundsCheck(array, index)
>>> that could be used in such cases that implemented using the more efficient
>>> (using C): (unsigned)index >= (unsigned)array.length, plus relied on more
>>> efficient VM throw mechanics on failure.
>> 
>> We need an intrinsic like this for Arrays 2.0. Might as well do it now, since we have an immediate application. 
>> 
>> Counterpoint:  optimizer can and should generate similar code for plain user written range tests. 
>> 
>> Advice:  Do both, and the intrinsic will give everybody a clearer target to aim for. Unit test the intrinsic optimization, and several similar formulations. 
>> 
>> ? John
> 


From vladimir.kozlov at oracle.com  Wed May  7 21:27:22 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 07 May 2014 14:27:22 -0700
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
	<536978D0.7060901@oracle.com>
	<3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com>
Message-ID: <536AA53A.7050408@oracle.com>

On 5/7/14 12:37 AM, Igor Veresov wrote:
> Vladimir,
>
> Thanks for the review!
> Please find the reply inline.
>
> igor
>
> On May 6, 2014, at 5:05 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> I think we need to let SAP know about this change (counter code in C2) since it may affect their tiered compilation. It use the same Deoptimization::Reason_age.
>>
> Oh, I didn?t know that. I?ll introduce another constant.
>
>> Can you separate C1 trap_request newa code in a separate RFE and push it first?
>>
>
> Do you think this is necessary? It so happens that the DeoptimizeStub was not used before this by any code. So the aging scheme is the only user of it so far.

I am fine to keep it in this fix but I can't review it. Ask Christian to 
look.

>
>> Can you add the field to MDO and not to MethodCounters? We doing this only for methods which were compiled already and have MDO. MethodCounters small size is important.
>
> It was in MDO originally, unfortunately I have to make it work for pure C1 and we usually don?t allocate MDOs in that configuration. Although, we need to only allocate MDOs for methods with aging, a set of which may be would be smallish..  But MDOs are kind of big.. Would that be better?

I forgot about pure C1.
Chris Plummer pointed me, for RTM changes, MethodCounters are allocated 
for all executed methods which may not be compiled. About 30% methods 
are executed.

>
>> Why the change in methodData.hpp and nmethod.cpp? '||' should be '&&' in nmethod::inc_decompile_count(), I think.
>
> You?re right, for pure C1 that won?t work anyways, because there are no MDOs. I?ll remove these for now. I probably need another decompile counter to put a cap on the number of recompiles, see the idea below.
>
>> In globals.hpp flags description indention is off.
>>
>
> Fixed.

You moved it to opposite direction :) . Indention of all comments are 
the same in the file. They are not aligned to a flag's declaration line.

>
>> sweeper.cpp:
>>
>> // The stack-scanning low-cost detection may not see the method was used (which can happen for
>>
>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in the existing

You did not change above comments as I suggested.

>>
>> Why do you need to repeat? For small leaf nmethods (with no safepoint, for example) it could trigger continues recompilation:
>>
>> +             if (time_since_reset > MinPassesBeforeFlush * 2) {
>> +               // It's been long enough, we still haven't seen it on stack.
>> +               // Try to flush it, but enable counters the next time.
>> +               mc->reset_nmethod_age();
>>
>
> That?s a good question. Before this change we would?ve recompiled warm methods continuously (given some code cache pressure), so the number of such cases is probably small. The options here with the code aging are:
> - don?t ever again flush a method that we?ve seen deopt once;
> - allow the flusher machinery to get rid of it if it becomes idle again.
>
> Currently I decided to stick with the latter but also give the method twice the standard time initially to be noticed by the stack-walker. You are right that there is a problem for small methods. Technically there is always one safepoint in the epilog though, right? I?m good with either option. Vladimir, what are your thoughts on this? Albert, if you skimming through this, what do you think?
>
> Here is an idea... We could count the number of decompiles for this particular reason and use it to scale the number of stack-walks we have to do before we flush the method again. For example we can wait MinPassesBeforeFlush * number_of_aging_deopts() stack-walks. Essentially this makes it unflushable in the limit - a combination of the two options above.
> I?ll need to allocate an MDO or add another counter to methodCounters for that though, or pack a small value info method_age itself, at the expense of a slightly bigger code. And there is an MT problem, as usual, with counting the number of deopts.

As we discussed the check will be scaled by number of recompilation.

Thanks,
Vladimir

>
> Here is the updated (with the changes addressed so far) webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/
>
> Thanks,
> igor
>
>> Thanks,
>> Vladimir
>>
>> On 5/5/14 7:44 PM, Igor Veresov wrote:
>>> The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows:
>>>
>>> 1. Initially a method is compiled as usual (no instrumentation, no overhead).
>>> 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code.
>>> 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter.
>>> 4. The value of the counter is then used by the sweeper to determine is the method is in fact used.
>>> 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again.
>>>
>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>>>
>>> Testing:
>>> - jprt,
>>> - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations.
>>>
>>> igor
>>>
>

From meisam.fathi at gmail.com  Thu May  8 01:17:08 2014
From: meisam.fathi at gmail.com (Meisam Fathi)
Date: Wed, 7 May 2014 21:17:08 -0400
Subject: Adding read barriers to the interpreter
In-Reply-To: <CAByMnGskLS-0JxaeTdtjg+LwYk3aDOUEbYVqoPRVZK-9xPRbAQ@mail.gmail.com>
References: <CAByMnGskLS-0JxaeTdtjg+LwYk3aDOUEbYVqoPRVZK-9xPRbAQ@mail.gmail.com>
Message-ID: <CAByMnGv9Ejj=Ge4X1Eg6Teo585zDpXi274UxZxpKn7qzve-eNA@mail.gmail.com>

Hi,

I nee to add read barriers before putfield and get field instructions in
the hotspot interpreter.
Would somebody direct me to the point in the code where I should add read
or write barriers?

Thanks,
Meisam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140507/219463e9/attachment.html>

From albert.noll at oracle.com  Thu May  8 05:34:53 2014
From: albert.noll at oracle.com (Albert)
Date: Thu, 08 May 2014 07:34:53 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <536A68A6.4090104@oracle.com>
References: <5368D8E7.6000800@oracle.com>	<5368DDDE.7020908@oracle.com>	<5368E1F4.50308@oracle.com>	<5368E2C9.9030704@oracle.com>	<5368E4AE.5020802@oracle.com>	<536924FF.6080309@oracle.com>	<536A4C83.4030805@oracle.com>
	<536A599A.4070905@oracle.com> <536A68A6.4090104@oracle.com>
Message-ID: <536B177D.7010906@oracle.com>

Hi Vladimir,

that sounds like a good suggestion to me. Here is the updated webrev:
http://cr.openjdk.java.net/~anoll/8042431/webrev.03/

Thanks for looking at this again.

Best,
Albert

On 05/07/2014 07:08 PM, Vladimir Kozlov wrote:
> I just saw Severin's comment.
>
> The check we have already verifies that minimum <= CI_COMPILER_COUNT 
> when CICompilerCount is not specified on command line. But to have 
> explicit assert is better, I think:
>
>   int min_number_of_compiler_threads = 
> get_min_number_of_compiler_threads();
>   // The default CICompilerCount's value is CI_COMPILER_COUNT.
>   assert(min_number_of_compiler_threads <= CI_COMPILER_COUNT, "minimum 
> should be less or equal default number");
>   // Check the minimum number of compiler threads.
>   status &=verify_min_value(CICompilerCount, 
> min_number_of_compiler_threads, "CICompilerCount");
>
> Thanks,
> Vladimir
>
> On 5/7/14 9:04 AM, Vladimir Kozlov wrote:
>> Good.
>>
>> Thanks,
>> Vladimir
>>
>> On 5/7/14 8:08 AM, Albert wrote:
>>> Hi Vladimir,
>>>
>>> thanks for looking at this. I followed your suggestions and adapted 
>>> the webrev accordingly.
>>> Here is the new version:
>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.02/
>>>
>>> Best,
>>> Albert
>>>
>>> On 05/06/2014 08:07 PM, Vladimir Kozlov wrote:
>>>> The default for C2 non-tiered should be 2, not 1.
>>>>
>>>> We are mixing 2 things: minimum value and default value. The 
>>>> default is CI_COMPILER_COUNT.
>>>>
>>>> Next statement is wrong for ZERO VM:
>>>> "A value of 2 works for any platform/configuration."
>>>>
>>>> I don't think we should change globals.hpp, leave it as it is.
>>>>
>>>> We only need to fix the minimum check. The bug is that we used 
>>>> default CI_COMPILER_COUNT as minimum value which is
>>>> wrong.
>>>>
>>>> The fix should be:
>>>>
>>>> +   // Check the minimum number of compiler threads
>>>> +   status &=verify_min_value(CICompilerCount, 
>>>> get_min_number_of_compiler_threads(), "CICompilerCount");
>>>>
>>>> Note, don't reset the default setting.
>>>>
>>>> You can reduce size of new method more:
>>>>
>>>> + int Arguments::get_min_number_of_compiler_threads() {
>>>> + #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK)
>>>> +   return 0;   // case 1: no compilers (Zero VM)
>>>> + #else
>>>> +   if (!TieredCompilation || (TieredStopAtLevel < 
>>>> CompLevel_full_optimization)) {
>>>> +     return 1; // case 2 or case 3
>>>> +   }
>>>> +   return 2;   // case 4 (tiered).
>>>> + #endif
>>>> + }
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 5/6/14 6:33 AM, Albert wrote:
>>>>> Hi Niclas,
>>>>>
>>>>> thanks for your suggestions. Your version is much nicer. Here is the
>>>>> updated webrev:
>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.01/
>>>>>
>>>>> Thanks,
>>>>> Albert
>>>>>
>>>>> On 05/06/2014 03:25 PM, Niclas Adlertz wrote:
>>>>>> Hi, see my previous answer. If would suggest to change the nested
>>>>>> if-else cases to:
>>>>>>
>>>>>> // case 1
>>>>>> if (no_compiler) {
>>>>>>   return 0;
>>>>>> }
>>>>>>
>>>>>> // case 2 or 3
>>>>>> if (!TieredCompilation || TieredStopAtLevel <
>>>>>> CompLevel_full_optimization) {
>>>>>>   return 1;
>>>>>> }
>>>>>>
>>>>>> // case 4 (default case, works on all platforms)
>>>>>> return 2
>>>>>>
>>>>>> Kind Regards,
>>>>>> Niclas Adlertz
>>>>>>
>>>>>> On 05/06/2014 03:21 PM, Albert wrote:
>>>>>>> Hi Niclas,
>>>>>>>
>>>>>>> thanks for looking at this. Please see comment inline.
>>>>>>> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
>>>>>>>> Hi Albert,
>>>>>>>>
>>>>>>>> Inside src/share/vm/runtime/arguments.cpp:
>>>>>>>> +   // We should not come here. However, we also do not fail 
>>>>>>>> the VM,
>>>>>>>> since this is a not-critical error.
>>>>>>>> +   assert (false, "Missed configuration to set the minimum 
>>>>>>>> number of
>>>>>>>> compiler threads.");
>>>>>>>> +   // Return 2, since this works with all configurations on all
>>>>>>>> platforms.
>>>>>>>> +   return 2;
>>>>>>>>
>>>>>>>> That is dead code, and we can remove it.
>>>>>>>> If none of the cases 1, 2 or 3 are true, we will always enter 
>>>>>>>> case 4.
>>>>>>> That code is there to make sure (in case someone makes changes 
>>>>>>> to that
>>>>>>> function)
>>>>>>> that the default return value is 2, since this works for all 
>>>>>>> platforms.
>>>>>>>
>>>>>>> Do you think that leaving a comment is good enough (or not even 
>>>>>>> that)?
>>>>>>>
>>>>>>>>
>>>>>>>> Kind Regards,
>>>>>>>> Niclas Adlertz
>>>>>>>>
>>>>>>>> On 05/06/2014 02:43 PM, Albert wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> could I get reviews for this patch?
>>>>>>>>>
>>>>>>>>> Bug:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>>>>>>>>
>>>>>>>>> Problem:
>>>>>>>>> The minimum number of compiler threads is set incorrectly.
>>>>>>>>>
>>>>>>>>> Solution:
>>>>>>>>> Define a new function 'get_min_number_of_compiler_threads()' that
>>>>>>>>> determines the minimum number of compiler threads for a 
>>>>>>>>> particular
>>>>>>>>> platform/configuration.
>>>>>>>>>
>>>>>>>>> Testing:
>>>>>>>>> Failing test case; zero; -XX:-TieredCompilation 
>>>>>>>>> -XX:CICompilerCount=1
>>>>>>>>>
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>>>>>>>>
>>>>>>>>> Many thanks in advance,
>>>>>>>>> Albert
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>


From staffan.larsen at oracle.com  Thu May  8 06:06:54 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 8 May 2014 08:06:54 +0200
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with
	assert(_cur_stack_depth == count_frames()) failed:
	cur_stack_depth out of sync
Message-ID: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>

All, 

This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.

When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.

The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.

Kudos to Rickard for helping me write the code.

webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8041934

The fix has been verified by running the failing test in JPRT with -Xcomp.

Thanks,
/Staffan

From vladimir.kozlov at oracle.com  Thu May  8 09:00:44 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 08 May 2014 02:00:44 -0700
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <536B177D.7010906@oracle.com>
References: <5368D8E7.6000800@oracle.com>	<5368DDDE.7020908@oracle.com>	<5368E1F4.50308@oracle.com>	<5368E2C9.9030704@oracle.com>	<5368E4AE.5020802@oracle.com>	<536924FF.6080309@oracle.com>	<536A4C83.4030805@oracle.com>	<536A599A.4070905@oracle.com>
	<536A68A6.4090104@oracle.com> <536B177D.7010906@oracle.com>
Message-ID: <536B47BC.6060106@oracle.com>

Excellent.

Thanks,
Vladimir

On 5/7/14 10:34 PM, Albert wrote:
> Hi Vladimir,
>
> that sounds like a good suggestion to me. Here is the updated webrev:
> http://cr.openjdk.java.net/~anoll/8042431/webrev.03/
>
> Thanks for looking at this again.
>
> Best,
> Albert
>
> On 05/07/2014 07:08 PM, Vladimir Kozlov wrote:
>> I just saw Severin's comment.
>>
>> The check we have already verifies that minimum <= CI_COMPILER_COUNT when CICompilerCount is not specified on command
>> line. But to have explicit assert is better, I think:
>>
>>   int min_number_of_compiler_threads = get_min_number_of_compiler_threads();
>>   // The default CICompilerCount's value is CI_COMPILER_COUNT.
>>   assert(min_number_of_compiler_threads <= CI_COMPILER_COUNT, "minimum should be less or equal default number");
>>   // Check the minimum number of compiler threads.
>>   status &=verify_min_value(CICompilerCount, min_number_of_compiler_threads, "CICompilerCount");
>>
>> Thanks,
>> Vladimir
>>
>> On 5/7/14 9:04 AM, Vladimir Kozlov wrote:
>>> Good.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/7/14 8:08 AM, Albert wrote:
>>>> Hi Vladimir,
>>>>
>>>> thanks for looking at this. I followed your suggestions and adapted the webrev accordingly.
>>>> Here is the new version:
>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.02/
>>>>
>>>> Best,
>>>> Albert
>>>>
>>>> On 05/06/2014 08:07 PM, Vladimir Kozlov wrote:
>>>>> The default for C2 non-tiered should be 2, not 1.
>>>>>
>>>>> We are mixing 2 things: minimum value and default value. The default is CI_COMPILER_COUNT.
>>>>>
>>>>> Next statement is wrong for ZERO VM:
>>>>> "A value of 2 works for any platform/configuration."
>>>>>
>>>>> I don't think we should change globals.hpp, leave it as it is.
>>>>>
>>>>> We only need to fix the minimum check. The bug is that we used default CI_COMPILER_COUNT as minimum value which is
>>>>> wrong.
>>>>>
>>>>> The fix should be:
>>>>>
>>>>> +   // Check the minimum number of compiler threads
>>>>> +   status &=verify_min_value(CICompilerCount, get_min_number_of_compiler_threads(), "CICompilerCount");
>>>>>
>>>>> Note, don't reset the default setting.
>>>>>
>>>>> You can reduce size of new method more:
>>>>>
>>>>> + int Arguments::get_min_number_of_compiler_threads() {
>>>>> + #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK)
>>>>> +   return 0;   // case 1: no compilers (Zero VM)
>>>>> + #else
>>>>> +   if (!TieredCompilation || (TieredStopAtLevel < CompLevel_full_optimization)) {
>>>>> +     return 1; // case 2 or case 3
>>>>> +   }
>>>>> +   return 2;   // case 4 (tiered).
>>>>> + #endif
>>>>> + }
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 5/6/14 6:33 AM, Albert wrote:
>>>>>> Hi Niclas,
>>>>>>
>>>>>> thanks for your suggestions. Your version is much nicer. Here is the
>>>>>> updated webrev:
>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.01/
>>>>>>
>>>>>> Thanks,
>>>>>> Albert
>>>>>>
>>>>>> On 05/06/2014 03:25 PM, Niclas Adlertz wrote:
>>>>>>> Hi, see my previous answer. If would suggest to change the nested
>>>>>>> if-else cases to:
>>>>>>>
>>>>>>> // case 1
>>>>>>> if (no_compiler) {
>>>>>>>   return 0;
>>>>>>> }
>>>>>>>
>>>>>>> // case 2 or 3
>>>>>>> if (!TieredCompilation || TieredStopAtLevel <
>>>>>>> CompLevel_full_optimization) {
>>>>>>>   return 1;
>>>>>>> }
>>>>>>>
>>>>>>> // case 4 (default case, works on all platforms)
>>>>>>> return 2
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>> Niclas Adlertz
>>>>>>>
>>>>>>> On 05/06/2014 03:21 PM, Albert wrote:
>>>>>>>> Hi Niclas,
>>>>>>>>
>>>>>>>> thanks for looking at this. Please see comment inline.
>>>>>>>> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
>>>>>>>>> Hi Albert,
>>>>>>>>>
>>>>>>>>> Inside src/share/vm/runtime/arguments.cpp:
>>>>>>>>> +   // We should not come here. However, we also do not fail the VM,
>>>>>>>>> since this is a not-critical error.
>>>>>>>>> +   assert (false, "Missed configuration to set the minimum number of
>>>>>>>>> compiler threads.");
>>>>>>>>> +   // Return 2, since this works with all configurations on all
>>>>>>>>> platforms.
>>>>>>>>> +   return 2;
>>>>>>>>>
>>>>>>>>> That is dead code, and we can remove it.
>>>>>>>>> If none of the cases 1, 2 or 3 are true, we will always enter case 4.
>>>>>>>> That code is there to make sure (in case someone makes changes to that
>>>>>>>> function)
>>>>>>>> that the default return value is 2, since this works for all platforms.
>>>>>>>>
>>>>>>>> Do you think that leaving a comment is good enough (or not even that)?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Kind Regards,
>>>>>>>>> Niclas Adlertz
>>>>>>>>>
>>>>>>>>> On 05/06/2014 02:43 PM, Albert wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> could I get reviews for this patch?
>>>>>>>>>>
>>>>>>>>>> Bug:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>>>>>>>>>
>>>>>>>>>> Problem:
>>>>>>>>>> The minimum number of compiler threads is set incorrectly.
>>>>>>>>>>
>>>>>>>>>> Solution:
>>>>>>>>>> Define a new function 'get_min_number_of_compiler_threads()' that
>>>>>>>>>> determines the minimum number of compiler threads for a particular
>>>>>>>>>> platform/configuration.
>>>>>>>>>>
>>>>>>>>>> Testing:
>>>>>>>>>> Failing test case; zero; -XX:-TieredCompilation -XX:CICompilerCount=1
>>>>>>>>>>
>>>>>>>>>> Webrev:
>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Many thanks in advance,
>>>>>>>>>> Albert
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>

From albert.noll at oracle.com  Thu May  8 09:07:35 2014
From: albert.noll at oracle.com (Albert)
Date: Thu, 08 May 2014 11:07:35 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <536B47BC.6060106@oracle.com>
References: <5368D8E7.6000800@oracle.com>	<5368DDDE.7020908@oracle.com>	<5368E1F4.50308@oracle.com>	<5368E2C9.9030704@oracle.com>	<5368E4AE.5020802@oracle.com>	<536924FF.6080309@oracle.com>	<536A4C83.4030805@oracle.com>	<536A599A.4070905@oracle.com>	<536A68A6.4090104@oracle.com>
	<536B177D.7010906@oracle.com> <536B47BC.6060106@oracle.com>
Message-ID: <536B4957.3060403@oracle.com>

Thanks for the review, Vladimir.
Do I need a second one?

Best,
Albert

On 05/08/2014 11:00 AM, Vladimir Kozlov wrote:
> Excellent.
>
> Thanks,
> Vladimir
>
> On 5/7/14 10:34 PM, Albert wrote:
>> Hi Vladimir,
>>
>> that sounds like a good suggestion to me. Here is the updated webrev:
>> http://cr.openjdk.java.net/~anoll/8042431/webrev.03/
>>
>> Thanks for looking at this again.
>>
>> Best,
>> Albert
>>
>> On 05/07/2014 07:08 PM, Vladimir Kozlov wrote:
>>> I just saw Severin's comment.
>>>
>>> The check we have already verifies that minimum <= CI_COMPILER_COUNT 
>>> when CICompilerCount is not specified on command
>>> line. But to have explicit assert is better, I think:
>>>
>>>   int min_number_of_compiler_threads = 
>>> get_min_number_of_compiler_threads();
>>>   // The default CICompilerCount's value is CI_COMPILER_COUNT.
>>>   assert(min_number_of_compiler_threads <= CI_COMPILER_COUNT, 
>>> "minimum should be less or equal default number");
>>>   // Check the minimum number of compiler threads.
>>>   status &=verify_min_value(CICompilerCount, 
>>> min_number_of_compiler_threads, "CICompilerCount");
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/7/14 9:04 AM, Vladimir Kozlov wrote:
>>>> Good.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 5/7/14 8:08 AM, Albert wrote:
>>>>> Hi Vladimir,
>>>>>
>>>>> thanks for looking at this. I followed your suggestions and 
>>>>> adapted the webrev accordingly.
>>>>> Here is the new version:
>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.02/
>>>>>
>>>>> Best,
>>>>> Albert
>>>>>
>>>>> On 05/06/2014 08:07 PM, Vladimir Kozlov wrote:
>>>>>> The default for C2 non-tiered should be 2, not 1.
>>>>>>
>>>>>> We are mixing 2 things: minimum value and default value. The 
>>>>>> default is CI_COMPILER_COUNT.
>>>>>>
>>>>>> Next statement is wrong for ZERO VM:
>>>>>> "A value of 2 works for any platform/configuration."
>>>>>>
>>>>>> I don't think we should change globals.hpp, leave it as it is.
>>>>>>
>>>>>> We only need to fix the minimum check. The bug is that we used 
>>>>>> default CI_COMPILER_COUNT as minimum value which is
>>>>>> wrong.
>>>>>>
>>>>>> The fix should be:
>>>>>>
>>>>>> +   // Check the minimum number of compiler threads
>>>>>> +   status &=verify_min_value(CICompilerCount, 
>>>>>> get_min_number_of_compiler_threads(), "CICompilerCount");
>>>>>>
>>>>>> Note, don't reset the default setting.
>>>>>>
>>>>>> You can reduce size of new method more:
>>>>>>
>>>>>> + int Arguments::get_min_number_of_compiler_threads() {
>>>>>> + #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK)
>>>>>> +   return 0;   // case 1: no compilers (Zero VM)
>>>>>> + #else
>>>>>> +   if (!TieredCompilation || (TieredStopAtLevel < 
>>>>>> CompLevel_full_optimization)) {
>>>>>> +     return 1; // case 2 or case 3
>>>>>> +   }
>>>>>> +   return 2;   // case 4 (tiered).
>>>>>> + #endif
>>>>>> + }
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 5/6/14 6:33 AM, Albert wrote:
>>>>>>> Hi Niclas,
>>>>>>>
>>>>>>> thanks for your suggestions. Your version is much nicer. Here is 
>>>>>>> the
>>>>>>> updated webrev:
>>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.01/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Albert
>>>>>>>
>>>>>>> On 05/06/2014 03:25 PM, Niclas Adlertz wrote:
>>>>>>>> Hi, see my previous answer. If would suggest to change the nested
>>>>>>>> if-else cases to:
>>>>>>>>
>>>>>>>> // case 1
>>>>>>>> if (no_compiler) {
>>>>>>>>   return 0;
>>>>>>>> }
>>>>>>>>
>>>>>>>> // case 2 or 3
>>>>>>>> if (!TieredCompilation || TieredStopAtLevel <
>>>>>>>> CompLevel_full_optimization) {
>>>>>>>>   return 1;
>>>>>>>> }
>>>>>>>>
>>>>>>>> // case 4 (default case, works on all platforms)
>>>>>>>> return 2
>>>>>>>>
>>>>>>>> Kind Regards,
>>>>>>>> Niclas Adlertz
>>>>>>>>
>>>>>>>> On 05/06/2014 03:21 PM, Albert wrote:
>>>>>>>>> Hi Niclas,
>>>>>>>>>
>>>>>>>>> thanks for looking at this. Please see comment inline.
>>>>>>>>> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
>>>>>>>>>> Hi Albert,
>>>>>>>>>>
>>>>>>>>>> Inside src/share/vm/runtime/arguments.cpp:
>>>>>>>>>> +   // We should not come here. However, we also do not fail 
>>>>>>>>>> the VM,
>>>>>>>>>> since this is a not-critical error.
>>>>>>>>>> +   assert (false, "Missed configuration to set the minimum 
>>>>>>>>>> number of
>>>>>>>>>> compiler threads.");
>>>>>>>>>> +   // Return 2, since this works with all configurations on all
>>>>>>>>>> platforms.
>>>>>>>>>> +   return 2;
>>>>>>>>>>
>>>>>>>>>> That is dead code, and we can remove it.
>>>>>>>>>> If none of the cases 1, 2 or 3 are true, we will always enter 
>>>>>>>>>> case 4.
>>>>>>>>> That code is there to make sure (in case someone makes changes 
>>>>>>>>> to that
>>>>>>>>> function)
>>>>>>>>> that the default return value is 2, since this works for all 
>>>>>>>>> platforms.
>>>>>>>>>
>>>>>>>>> Do you think that leaving a comment is good enough (or not 
>>>>>>>>> even that)?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Kind Regards,
>>>>>>>>>> Niclas Adlertz
>>>>>>>>>>
>>>>>>>>>> On 05/06/2014 02:43 PM, Albert wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> could I get reviews for this patch?
>>>>>>>>>>>
>>>>>>>>>>> Bug:
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>>>>>>>>>>
>>>>>>>>>>> Problem:
>>>>>>>>>>> The minimum number of compiler threads is set incorrectly.
>>>>>>>>>>>
>>>>>>>>>>> Solution:
>>>>>>>>>>> Define a new function 'get_min_number_of_compiler_threads()' 
>>>>>>>>>>> that
>>>>>>>>>>> determines the minimum number of compiler threads for a 
>>>>>>>>>>> particular
>>>>>>>>>>> platform/configuration.
>>>>>>>>>>>
>>>>>>>>>>> Testing:
>>>>>>>>>>> Failing test case; zero; -XX:-TieredCompilation 
>>>>>>>>>>> -XX:CICompilerCount=1
>>>>>>>>>>>
>>>>>>>>>>> Webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> Many thanks in advance,
>>>>>>>>>>> Albert
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>


From tobias.hartmann at oracle.com  Thu May  8 09:30:20 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 08 May 2014 11:30:20 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <536B4957.3060403@oracle.com>
References: <5368D8E7.6000800@oracle.com>	<5368DDDE.7020908@oracle.com>	<5368E1F4.50308@oracle.com>	<5368E2C9.9030704@oracle.com>	<5368E4AE.5020802@oracle.com>	<536924FF.6080309@oracle.com>	<536A4C83.4030805@oracle.com>	<536A599A.4070905@oracle.com>	<536A68A6.4090104@oracle.com>	<536B177D.7010906@oracle.com>
	<536B47BC.6060106@oracle.com> <536B4957.3060403@oracle.com>
Message-ID: <536B4EAC.6050500@oracle.com>

Looks good to me.

Regards,
Tobias

On 08.05.2014 11:07, Albert wrote:
> Thanks for the review, Vladimir.
> Do I need a second one?
>
> Best,
> Albert
>
> On 05/08/2014 11:00 AM, Vladimir Kozlov wrote:
>> Excellent.
>>
>> Thanks,
>> Vladimir
>>
>> On 5/7/14 10:34 PM, Albert wrote:
>>> Hi Vladimir,
>>>
>>> that sounds like a good suggestion to me. Here is the updated webrev:
>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.03/
>>>
>>> Thanks for looking at this again.
>>>
>>> Best,
>>> Albert
>>>
>>> On 05/07/2014 07:08 PM, Vladimir Kozlov wrote:
>>>> I just saw Severin's comment.
>>>>
>>>> The check we have already verifies that minimum <= 
>>>> CI_COMPILER_COUNT when CICompilerCount is not specified on command
>>>> line. But to have explicit assert is better, I think:
>>>>
>>>>   int min_number_of_compiler_threads = 
>>>> get_min_number_of_compiler_threads();
>>>>   // The default CICompilerCount's value is CI_COMPILER_COUNT.
>>>>   assert(min_number_of_compiler_threads <= CI_COMPILER_COUNT, 
>>>> "minimum should be less or equal default number");
>>>>   // Check the minimum number of compiler threads.
>>>>   status &=verify_min_value(CICompilerCount, 
>>>> min_number_of_compiler_threads, "CICompilerCount");
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 5/7/14 9:04 AM, Vladimir Kozlov wrote:
>>>>> Good.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 5/7/14 8:08 AM, Albert wrote:
>>>>>> Hi Vladimir,
>>>>>>
>>>>>> thanks for looking at this. I followed your suggestions and 
>>>>>> adapted the webrev accordingly.
>>>>>> Here is the new version:
>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.02/
>>>>>>
>>>>>> Best,
>>>>>> Albert
>>>>>>
>>>>>> On 05/06/2014 08:07 PM, Vladimir Kozlov wrote:
>>>>>>> The default for C2 non-tiered should be 2, not 1.
>>>>>>>
>>>>>>> We are mixing 2 things: minimum value and default value. The 
>>>>>>> default is CI_COMPILER_COUNT.
>>>>>>>
>>>>>>> Next statement is wrong for ZERO VM:
>>>>>>> "A value of 2 works for any platform/configuration."
>>>>>>>
>>>>>>> I don't think we should change globals.hpp, leave it as it is.
>>>>>>>
>>>>>>> We only need to fix the minimum check. The bug is that we used 
>>>>>>> default CI_COMPILER_COUNT as minimum value which is
>>>>>>> wrong.
>>>>>>>
>>>>>>> The fix should be:
>>>>>>>
>>>>>>> +   // Check the minimum number of compiler threads
>>>>>>> +   status &=verify_min_value(CICompilerCount, 
>>>>>>> get_min_number_of_compiler_threads(), "CICompilerCount");
>>>>>>>
>>>>>>> Note, don't reset the default setting.
>>>>>>>
>>>>>>> You can reduce size of new method more:
>>>>>>>
>>>>>>> + int Arguments::get_min_number_of_compiler_threads() {
>>>>>>> + #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK)
>>>>>>> +   return 0;   // case 1: no compilers (Zero VM)
>>>>>>> + #else
>>>>>>> +   if (!TieredCompilation || (TieredStopAtLevel < 
>>>>>>> CompLevel_full_optimization)) {
>>>>>>> +     return 1; // case 2 or case 3
>>>>>>> +   }
>>>>>>> +   return 2;   // case 4 (tiered).
>>>>>>> + #endif
>>>>>>> + }
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 5/6/14 6:33 AM, Albert wrote:
>>>>>>>> Hi Niclas,
>>>>>>>>
>>>>>>>> thanks for your suggestions. Your version is much nicer. Here 
>>>>>>>> is the
>>>>>>>> updated webrev:
>>>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.01/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Albert
>>>>>>>>
>>>>>>>> On 05/06/2014 03:25 PM, Niclas Adlertz wrote:
>>>>>>>>> Hi, see my previous answer. If would suggest to change the nested
>>>>>>>>> if-else cases to:
>>>>>>>>>
>>>>>>>>> // case 1
>>>>>>>>> if (no_compiler) {
>>>>>>>>>   return 0;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> // case 2 or 3
>>>>>>>>> if (!TieredCompilation || TieredStopAtLevel <
>>>>>>>>> CompLevel_full_optimization) {
>>>>>>>>>   return 1;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> // case 4 (default case, works on all platforms)
>>>>>>>>> return 2
>>>>>>>>>
>>>>>>>>> Kind Regards,
>>>>>>>>> Niclas Adlertz
>>>>>>>>>
>>>>>>>>> On 05/06/2014 03:21 PM, Albert wrote:
>>>>>>>>>> Hi Niclas,
>>>>>>>>>>
>>>>>>>>>> thanks for looking at this. Please see comment inline.
>>>>>>>>>> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
>>>>>>>>>>> Hi Albert,
>>>>>>>>>>>
>>>>>>>>>>> Inside src/share/vm/runtime/arguments.cpp:
>>>>>>>>>>> +   // We should not come here. However, we also do not fail 
>>>>>>>>>>> the VM,
>>>>>>>>>>> since this is a not-critical error.
>>>>>>>>>>> +   assert (false, "Missed configuration to set the minimum 
>>>>>>>>>>> number of
>>>>>>>>>>> compiler threads.");
>>>>>>>>>>> +   // Return 2, since this works with all configurations on 
>>>>>>>>>>> all
>>>>>>>>>>> platforms.
>>>>>>>>>>> +   return 2;
>>>>>>>>>>>
>>>>>>>>>>> That is dead code, and we can remove it.
>>>>>>>>>>> If none of the cases 1, 2 or 3 are true, we will always 
>>>>>>>>>>> enter case 4.
>>>>>>>>>> That code is there to make sure (in case someone makes 
>>>>>>>>>> changes to that
>>>>>>>>>> function)
>>>>>>>>>> that the default return value is 2, since this works for all 
>>>>>>>>>> platforms.
>>>>>>>>>>
>>>>>>>>>> Do you think that leaving a comment is good enough (or not 
>>>>>>>>>> even that)?
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Kind Regards,
>>>>>>>>>>> Niclas Adlertz
>>>>>>>>>>>
>>>>>>>>>>> On 05/06/2014 02:43 PM, Albert wrote:
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> could I get reviews for this patch?
>>>>>>>>>>>>
>>>>>>>>>>>> Bug:
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>>>>>>>>>>>
>>>>>>>>>>>> Problem:
>>>>>>>>>>>> The minimum number of compiler threads is set incorrectly.
>>>>>>>>>>>>
>>>>>>>>>>>> Solution:
>>>>>>>>>>>> Define a new function 
>>>>>>>>>>>> 'get_min_number_of_compiler_threads()' that
>>>>>>>>>>>> determines the minimum number of compiler threads for a 
>>>>>>>>>>>> particular
>>>>>>>>>>>> platform/configuration.
>>>>>>>>>>>>
>>>>>>>>>>>> Testing:
>>>>>>>>>>>> Failing test case; zero; -XX:-TieredCompilation 
>>>>>>>>>>>> -XX:CICompilerCount=1
>>>>>>>>>>>>
>>>>>>>>>>>> Webrev:
>>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> Many thanks in advance,
>>>>>>>>>>>> Albert
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>


From albert.noll at oracle.com  Thu May  8 09:31:28 2014
From: albert.noll at oracle.com (Albert)
Date: Thu, 08 May 2014 11:31:28 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <536B4EAC.6050500@oracle.com>
References: <5368D8E7.6000800@oracle.com>	<5368DDDE.7020908@oracle.com>	<5368E1F4.50308@oracle.com>	<5368E2C9.9030704@oracle.com>	<5368E4AE.5020802@oracle.com>	<536924FF.6080309@oracle.com>	<536A4C83.4030805@oracle.com>	<536A599A.4070905@oracle.com>	<536A68A6.4090104@oracle.com>	<536B177D.7010906@oracle.com>
	<536B47BC.6060106@oracle.com> <536B4957.3060403@oracle.com>
	<536B4EAC.6050500@oracle.com>
Message-ID: <536B4EF0.2010805@oracle.com>

Thank you for looking at this, Tobias.

Best,
Albert

On 05/08/2014 11:30 AM, Tobias Hartmann wrote:
> Looks good to me.
>
> Regards,
> Tobias
>
> On 08.05.2014 11:07, Albert wrote:
>> Thanks for the review, Vladimir.
>> Do I need a second one?
>>
>> Best,
>> Albert
>>
>> On 05/08/2014 11:00 AM, Vladimir Kozlov wrote:
>>> Excellent.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/7/14 10:34 PM, Albert wrote:
>>>> Hi Vladimir,
>>>>
>>>> that sounds like a good suggestion to me. Here is the updated webrev:
>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.03/
>>>>
>>>> Thanks for looking at this again.
>>>>
>>>> Best,
>>>> Albert
>>>>
>>>> On 05/07/2014 07:08 PM, Vladimir Kozlov wrote:
>>>>> I just saw Severin's comment.
>>>>>
>>>>> The check we have already verifies that minimum <= 
>>>>> CI_COMPILER_COUNT when CICompilerCount is not specified on command
>>>>> line. But to have explicit assert is better, I think:
>>>>>
>>>>>   int min_number_of_compiler_threads = 
>>>>> get_min_number_of_compiler_threads();
>>>>>   // The default CICompilerCount's value is CI_COMPILER_COUNT.
>>>>>   assert(min_number_of_compiler_threads <= CI_COMPILER_COUNT, 
>>>>> "minimum should be less or equal default number");
>>>>>   // Check the minimum number of compiler threads.
>>>>>   status &=verify_min_value(CICompilerCount, 
>>>>> min_number_of_compiler_threads, "CICompilerCount");
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 5/7/14 9:04 AM, Vladimir Kozlov wrote:
>>>>>> Good.
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>>> On 5/7/14 8:08 AM, Albert wrote:
>>>>>>> Hi Vladimir,
>>>>>>>
>>>>>>> thanks for looking at this. I followed your suggestions and 
>>>>>>> adapted the webrev accordingly.
>>>>>>> Here is the new version:
>>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.02/
>>>>>>>
>>>>>>> Best,
>>>>>>> Albert
>>>>>>>
>>>>>>> On 05/06/2014 08:07 PM, Vladimir Kozlov wrote:
>>>>>>>> The default for C2 non-tiered should be 2, not 1.
>>>>>>>>
>>>>>>>> We are mixing 2 things: minimum value and default value. The 
>>>>>>>> default is CI_COMPILER_COUNT.
>>>>>>>>
>>>>>>>> Next statement is wrong for ZERO VM:
>>>>>>>> "A value of 2 works for any platform/configuration."
>>>>>>>>
>>>>>>>> I don't think we should change globals.hpp, leave it as it is.
>>>>>>>>
>>>>>>>> We only need to fix the minimum check. The bug is that we used 
>>>>>>>> default CI_COMPILER_COUNT as minimum value which is
>>>>>>>> wrong.
>>>>>>>>
>>>>>>>> The fix should be:
>>>>>>>>
>>>>>>>> +   // Check the minimum number of compiler threads
>>>>>>>> +   status &=verify_min_value(CICompilerCount, 
>>>>>>>> get_min_number_of_compiler_threads(), "CICompilerCount");
>>>>>>>>
>>>>>>>> Note, don't reset the default setting.
>>>>>>>>
>>>>>>>> You can reduce size of new method more:
>>>>>>>>
>>>>>>>> + int Arguments::get_min_number_of_compiler_threads() {
>>>>>>>> + #if !defined(COMPILER1) && !defined(COMPILER2) && 
>>>>>>>> !defined(SHARK)
>>>>>>>> +   return 0;   // case 1: no compilers (Zero VM)
>>>>>>>> + #else
>>>>>>>> +   if (!TieredCompilation || (TieredStopAtLevel < 
>>>>>>>> CompLevel_full_optimization)) {
>>>>>>>> +     return 1; // case 2 or case 3
>>>>>>>> +   }
>>>>>>>> +   return 2;   // case 4 (tiered).
>>>>>>>> + #endif
>>>>>>>> + }
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir
>>>>>>>>
>>>>>>>> On 5/6/14 6:33 AM, Albert wrote:
>>>>>>>>> Hi Niclas,
>>>>>>>>>
>>>>>>>>> thanks for your suggestions. Your version is much nicer. Here 
>>>>>>>>> is the
>>>>>>>>> updated webrev:
>>>>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.01/
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Albert
>>>>>>>>>
>>>>>>>>> On 05/06/2014 03:25 PM, Niclas Adlertz wrote:
>>>>>>>>>> Hi, see my previous answer. If would suggest to change the 
>>>>>>>>>> nested
>>>>>>>>>> if-else cases to:
>>>>>>>>>>
>>>>>>>>>> // case 1
>>>>>>>>>> if (no_compiler) {
>>>>>>>>>>   return 0;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> // case 2 or 3
>>>>>>>>>> if (!TieredCompilation || TieredStopAtLevel <
>>>>>>>>>> CompLevel_full_optimization) {
>>>>>>>>>>   return 1;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> // case 4 (default case, works on all platforms)
>>>>>>>>>> return 2
>>>>>>>>>>
>>>>>>>>>> Kind Regards,
>>>>>>>>>> Niclas Adlertz
>>>>>>>>>>
>>>>>>>>>> On 05/06/2014 03:21 PM, Albert wrote:
>>>>>>>>>>> Hi Niclas,
>>>>>>>>>>>
>>>>>>>>>>> thanks for looking at this. Please see comment inline.
>>>>>>>>>>> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
>>>>>>>>>>>> Hi Albert,
>>>>>>>>>>>>
>>>>>>>>>>>> Inside src/share/vm/runtime/arguments.cpp:
>>>>>>>>>>>> +   // We should not come here. However, we also do not 
>>>>>>>>>>>> fail the VM,
>>>>>>>>>>>> since this is a not-critical error.
>>>>>>>>>>>> +   assert (false, "Missed configuration to set the minimum 
>>>>>>>>>>>> number of
>>>>>>>>>>>> compiler threads.");
>>>>>>>>>>>> +   // Return 2, since this works with all configurations 
>>>>>>>>>>>> on all
>>>>>>>>>>>> platforms.
>>>>>>>>>>>> +   return 2;
>>>>>>>>>>>>
>>>>>>>>>>>> That is dead code, and we can remove it.
>>>>>>>>>>>> If none of the cases 1, 2 or 3 are true, we will always 
>>>>>>>>>>>> enter case 4.
>>>>>>>>>>> That code is there to make sure (in case someone makes 
>>>>>>>>>>> changes to that
>>>>>>>>>>> function)
>>>>>>>>>>> that the default return value is 2, since this works for all 
>>>>>>>>>>> platforms.
>>>>>>>>>>>
>>>>>>>>>>> Do you think that leaving a comment is good enough (or not 
>>>>>>>>>>> even that)?
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Kind Regards,
>>>>>>>>>>>> Niclas Adlertz
>>>>>>>>>>>>
>>>>>>>>>>>> On 05/06/2014 02:43 PM, Albert wrote:
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> could I get reviews for this patch?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bug:
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042431
>>>>>>>>>>>>>
>>>>>>>>>>>>> Problem:
>>>>>>>>>>>>> The minimum number of compiler threads is set incorrectly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Solution:
>>>>>>>>>>>>> Define a new function 
>>>>>>>>>>>>> 'get_min_number_of_compiler_threads()' that
>>>>>>>>>>>>> determines the minimum number of compiler threads for a 
>>>>>>>>>>>>> particular
>>>>>>>>>>>>> platform/configuration.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Testing:
>>>>>>>>>>>>> Failing test case; zero; -XX:-TieredCompilation 
>>>>>>>>>>>>> -XX:CICompilerCount=1
>>>>>>>>>>>>>
>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Many thanks in advance,
>>>>>>>>>>>>> Albert
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>>
>


From tobias.hartmann at oracle.com  Thu May  8 10:26:28 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 08 May 2014 12:26:28 +0200
Subject: [9] RFR(S): 8029343: CodeCache::allocate increments
	'_number_of_blobs' even if allocation fails.
In-Reply-To: <53692956.9060208@oracle.com>
References: <53688ECC.5020308@oracle.com>
	<53689237.9090609@oracle.com>	<5368D922.8060600@oracle.com>
	<53692956.9060208@oracle.com>
Message-ID: <536B5BD4.9020205@oracle.com>

Thank you Vladimir and Igor.

Can we push the changes?

Tobias

On 06.05.2014 20:26, Vladimir Kozlov wrote:
> On 5/6/14 5:44 AM, Tobias Hartmann wrote:
>> Hi Vladimir,
>>
>> On 06.05.2014 09:41, Vladimir Kozlov wrote:
>>> Parfait may complain about returning NULL and without guarantee.
>>> Please, test.
>>
>> I tested the implementation with parfait and no new defects showed up.
>
> Okay.
>
> Thanks,
> Vladimir
>
>>
>> Thanks,
>> Tobias
>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/6/14 12:27 AM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> please review the following patch for bug 8029343.
>>>>
>>>> *Problem:*
>>>> (1) CodeCache::allocate(...) increments _number_of_blobs before the
>>>> actual allocation is performed. In case the
>>>> allocation fails the counter is set to a wrong value.
>>>> (2) The guarantee(size >= 0, ...) is incorrect. Calling
>>>> CodeCache::allocate(...) with size = 0 leads to a segmentation
>>>> fault. Further, a guarantee is too strong here. We can simply return
>>>> NULL at runtime if the size is <= 0.
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029343
>>>>
>>>> *Solution:*
>>>> (1) The increment is moved after the allocation.
>>>> (2) An assert is used instead of the guarantee and NULL is returned
>>>> if size <= 0.
>>>> Webrev: http://cr.openjdk.java.net/~anoll/8029343/webrev.00/
>>>>
>>>> Thanks,
>>>> Tobias
>>


From nils.eliasson at oracle.com  Thu May  8 11:56:19 2014
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Thu, 08 May 2014 13:56:19 +0200
Subject: RFR(S): 8031475: Missing oopmap in patching stubs
In-Reply-To: <EA8ACCC3-22E4-4B96-93B8-C849196E5E6F@oracle.com>
References: <5360F539.9090408@oracle.com>
	<EA8ACCC3-22E4-4B96-93B8-C849196E5E6F@oracle.com>
Message-ID: <536B70E3.6070902@oracle.com>

answer inline.

On 2014-04-30 21:17, Christian Thalinger wrote:
>
> On Apr 30, 2014, at 3:06 AM, Nils Eliasson <nils.eliasson at oracle.com 
> <mailto:nils.eliasson at oracle.com>> wrote:
>
>> Hi,
>>
>> I would like some feedback on this change from the c1 experts. It's 
>> made in platform dependent code and will be added to the other 
>> plattforms as well before submit.
>>
>> This change fixes a bug that has been observed in testing, and dug up 
>> from a core file, but haven't reproduced standalone yet. When 
>> patching for checkcast the oop we are casting is not kept in an 
>> oopmap during the runtime patching call, a one time chance per run.
>>
>> The current change is for all the patching stub cases 
>> (access_field_id, load_klass_id, load_mirror_id, load_appendix_id) - 
>> is that needed? 
>
> This looks reasonable.  What you are saying is that at:
>
>  0x00007f20c94359c5: callq  0x00007f20c942e3e0  ; OopMap{[32]=Oop off=266}
>
> the OopMap does not contain the object (in this case in rdx) and so is 
> not handled during a GC, correct?

Yes

>
>> Do you see any potential for breaking anything? It is difficult to 
>> trigger a GC at exact this point during a test.
>
> Can?t you trigger a GC inside the runtime call by calling:
>
> Universe::heap()->collect(GCCause::_java_lang_system_gc);
>
> ?

Yes, that did the trick. Now I have a reliable reproducer.

Thank you!

//Nils

>
>>
>> http://cr.openjdk.java.net/~neliasso/8031475/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eneliasso/8031475/webrev.01/>
>> https://bugs.openjdk.java.net/browse/JDK-8031475
>>
>> Thanks,
>> Nils Eliasson
>>
>>
>> Code example:
>>
>>  0x00007f20c943590c: mov    $0x718d65d38,%rdx  ;   {oop(a 
>> 'BeanImpl2')}   // oops to be casted in rdx
>>  0x00007f20c9435916: cmp    $0x0,%rdx
>>  0x00007f20c943591a: je     0x00007f20c9435967   // jump to patching stub
>>  // patch location
>>  0x00007f20c9435920: jmpq   0x00007f20c94359c5  ;   {no_reloc}
>>  0x00007f20c9435925: add    %al,(%rax)
>>  0x00007f20c9435927: add    %al,(%rax)
>>  0x00007f20c9435929: add    %cl,-0x3eb7f786(%rbx)
>>  0x00007f20c943592f: out    %eax,$0x3
>>  // end of patch location
>>  0x00007f20c9435931: cmp    %rbx,%rdi
>>  0x00007f20c9435934: je     0x00007f20c9435967 // A dereference of 
>> rdx somewhere here may crash if the oop has moved during a gc
>>  0x00007f20c943593a: mov    0x10(%rbx),%esi
>>  0x00007f20c943593d: cmp    (%rdi,%rsi,1),%rbx
>>  0x00007f20c9435941: je     0x00007f20c9435967
>>
>>  ...
>>
>>  ;; PatchingStub slow case
>>  ;;  patch template
>>  0x00007f20c94359b6: mov    $0x0,%rbx          ;   {metadata(NULL)}
>>  ;; patch data encoded as movl
>>  0x00007f20c94359c0: mov    $0xa050f00,%eax
>>  ;; patch entry point
>>  0x00007f20c94359c5: callq  0x00007f20c942e3e0  ; OopMap{[32]=Oop 
>> off=266}   // rdx not live here, may safepoint on return from runtime 
>> call
>>                                                ;*checkcast
>>                                                ; - 
>> TestCheckCast::main at 25 (line 24)
>>                                                ;   {runtime_call}
>>  0x00007f20c94359ca: jmpq   0x00007f20c9435920   // back to normal 
>> control flow after patching
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140508/d6d44251/attachment.html>

From sgehwolf at redhat.com  Wed May  7 10:48:47 2014
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 07 May 2014 12:48:47 +0200
Subject: [9] RFR(S): 8042431: compiler/7200264/TestIntVect.java fails
	with: Test Failed: AddVI 0 < 4
In-Reply-To: <536924FF.6080309@oracle.com>
References: <5368D8E7.6000800@oracle.com> <5368DDDE.7020908@oracle.com>
	<5368E1F4.50308@oracle.com> <5368E2C9.9030704@oracle.com>
	<5368E4AE.5020802@oracle.com> <536924FF.6080309@oracle.com>
Message-ID: <1399459727.3481.8.camel@localhost.localdomain>

Hi,

On Tue, 2014-05-06 at 11:07 -0700, Vladimir Kozlov wrote:
> The default for C2 non-tiered should be 2, not 1.
> 
> We are mixing 2 things: minimum value and default value. The default is 
> CI_COMPILER_COUNT.

This information would be nice to have documented in
get_min_number_of_compiler_threads(). In particular, that
CI_COMPILER_COUNT is the *default* and the minimum value may be
different (but >= the default). My $0.02.

> Next statement is wrong for ZERO VM:
> "A value of 2 works for any platform/configuration."
> 
> I don't think we should change globals.hpp, leave it as it is.
> 
> We only need to fix the minimum check. The bug is that we used default 
> CI_COMPILER_COUNT as minimum value which is wrong.
> 
> The fix should be:
> 
> +   // Check the minimum number of compiler threads
> +   status &=verify_min_value(CICompilerCount, 
> get_min_number_of_compiler_threads(), "CICompilerCount");
> 
> Note, don't reset the default setting.
> 
> You can reduce size of new method more:
> 
> + int Arguments::get_min_number_of_compiler_threads() {
> + #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK)
> +   return 0;   // case 1: no compilers (Zero VM)
> + #else
> +   if (!TieredCompilation || (TieredStopAtLevel < 
> CompLevel_full_optimization)) {
> +     return 1; // case 2 or case 3
> +   }
> +   return 2;   // case 4 (tiered).
> + #endif
> + }

Thanks,
Severin

> On 5/6/14 6:33 AM, Albert wrote:
> > Hi Niclas,
> >
> > thanks for your suggestions. Your version is much nicer. Here is the
> > updated webrev:
> > http://cr.openjdk.java.net/~anoll/8042431/webrev.01/
> >
> > Thanks,
> > Albert
> >
> > On 05/06/2014 03:25 PM, Niclas Adlertz wrote:
> >> Hi, see my previous answer. If would suggest to change the nested
> >> if-else cases to:
> >>
> >> // case 1
> >> if (no_compiler) {
> >>   return 0;
> >> }
> >>
> >> // case 2 or 3
> >> if (!TieredCompilation || TieredStopAtLevel <
> >> CompLevel_full_optimization) {
> >>   return 1;
> >> }
> >>
> >> // case 4 (default case, works on all platforms)
> >> return 2
> >>
> >> Kind Regards,
> >> Niclas Adlertz
> >>
> >> On 05/06/2014 03:21 PM, Albert wrote:
> >>> Hi Niclas,
> >>>
> >>> thanks for looking at this. Please see comment inline.
> >>> On 05/06/2014 03:04 PM, Niclas Adlertz wrote:
> >>>> Hi Albert,
> >>>>
> >>>> Inside src/share/vm/runtime/arguments.cpp:
> >>>> +   // We should not come here. However, we also do not fail the VM,
> >>>> since this is a not-critical error.
> >>>> +   assert (false, "Missed configuration to set the minimum number of
> >>>> compiler threads.");
> >>>> +   // Return 2, since this works with all configurations on all
> >>>> platforms.
> >>>> +   return 2;
> >>>>
> >>>> That is dead code, and we can remove it.
> >>>> If none of the cases 1, 2 or 3 are true, we will always enter case 4.
> >>> That code is there to make sure (in case someone makes changes to that
> >>> function)
> >>> that the default return value is 2, since this works for all platforms.
> >>>
> >>> Do you think that leaving a comment is good enough (or not even that)?
> >>>
> >>>>
> >>>> Kind Regards,
> >>>> Niclas Adlertz
> >>>>
> >>>> On 05/06/2014 02:43 PM, Albert wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> could I get reviews for this patch?
> >>>>>
> >>>>> Bug:
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8042431
> >>>>>
> >>>>> Problem:
> >>>>> The minimum number of compiler threads is set incorrectly.
> >>>>>
> >>>>> Solution:
> >>>>> Define a new function 'get_min_number_of_compiler_threads()' that
> >>>>> determines the minimum number of compiler threads  for a particular
> >>>>> platform/configuration.
> >>>>>
> >>>>> Testing:
> >>>>> Failing test case; zero; -XX:-TieredCompilation -XX:CICompilerCount=1
> >>>>>
> >>>>> Webrev:
> >>>>> http://cr.openjdk.java.net/~anoll/8042431/webrev.00/
> >>>>>
> >>>>> Many thanks in advance,
> >>>>> Albert
> >>>>>
> >>>>>
> >>>
> >




From mikael.auno at oracle.com  Thu May  8 09:56:29 2014
From: mikael.auno at oracle.com (Mikael Auno)
Date: Thu, 08 May 2014 11:56:29 +0200
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms
	with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth
	out of sync
In-Reply-To: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>
Message-ID: <536B54CD.4090605@oracle.com>

Note that RepStep was just added to ProblemList due to this issue and
will have to be removed from there when the fix is integrated.

Mikael

On 2014-05-08 08:06, Staffan Larsen wrote:
> All, 
> 
> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
> 
> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
> 
> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
> 
> Kudos to Rickard for helping me write the code.
> 
> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8041934
> 
> The fix has been verified by running the failing test in JPRT with -Xcomp.
> 
> Thanks,
> /Staffan
> 


From filipp.zhinkin at oracle.com  Thu May  8 15:09:42 2014
From: filipp.zhinkin at oracle.com (Filipp Zhinkin)
Date: Thu, 08 May 2014 19:09:42 +0400
Subject: RFR: 8011397: JTREG needs to copy additional WhiteBox class file
	to JTwork/scratch/sun/hotspot
In-Reply-To: <536B7CF0.6010508@oracle.com>
References: <536B7CF0.6010508@oracle.com>
Message-ID: <536B9E36.6090802@oracle.com>

Andrey,

I've CC'ed compiler and runtime mailing list, because you're changes 
affect test for other components as too.

I don't like your solution (but I'm not a reviewer, so treat my words 
just as suggestion),
because we'll have to write more meta information for each test and it 
is very easy to
forget to install WhiteBoxPermission if you don't test your test with 
some security manager.

 From my point of view, it will be better to extend ClassFileInstaller 
so it will copy not only
a class whose name was passed as an arguments, but also all inner 
classes of that class.
And if someone want copy only specified class without inner classes, 
then some option
could be added to ClassFileInstaller to force such behaviour.

Thanks,
Filipp.

On 05/08/2014 04:47 PM, Andrey Zakharov wrote:
> Hi!
> Suggesting patch with fixes for 
> https://bugs.openjdk.java.net/browse/JDK-8011397
>
> webrev: https://bugs.openjdk.java.net/secure/attachment/20275/8011397.tgz
> patch: 
> https://bugs.openjdk.java.net/secure/attachment/20274/8011397.WhiteBoxPermission
>
>
> Thanks.


From daniel.daugherty at oracle.com  Thu May  8 17:05:29 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 08 May 2014 11:05:29 -0600
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms
	with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth
	out of sync
In-Reply-To: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>
Message-ID: <536BB959.7060706@oracle.com>

 > webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/

src/share/vm/runtime/sharedRuntime.hpp
     No comments.

src/share/vm/runtime/sharedRuntime.cpp
     line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit(
         I'm not sure that JRT_LEAF is right. I would think that
         JvmtiExport::post_method_exit() would have to grab one or
         more locks with all the state checks it has to make...

         For reference, InterpreterRuntime::post_method_exit()
         is a wrapper around JvmtiExport::post_method_exit()
         and it is IRT_ENTRY instead of IRT_LEAF.

src/cpu/sparc/vm/sharedRuntime_sparc.cpp
     No comments.

src/cpu/x86/vm/sharedRuntime_x86_32.cpp
     No comments.

src/cpu/x86/vm/sharedRuntime_x86_64.cpp
     No comments.

I'm guessing that PPC has the same issue, but I'm presuming
that someone else (Vladimir?) will handle that...

Dan


On 5/8/14 12:06 AM, Staffan Larsen wrote:
> All,
>
> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
>
> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
>
> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
>
> Kudos to Rickard for helping me write the code.
>
> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8041934
>
> The fix has been verified by running the failing test in JPRT with -Xcomp.
>
> Thanks,
> /Staffan


From igor.veresov at oracle.com  Thu May  8 19:30:33 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 8 May 2014 12:30:33 -0700
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <536AA53A.7050408@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
	<536978D0.7060901@oracle.com>
	<3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com>
	<536AA53A.7050408@oracle.com>
Message-ID: <1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com>

Alright, here is the update: http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/

The change is that I added a trap counter in the MDO that is used to scale up the number of stack walks that are necessary for the tenured method to revert back to the standard flushing policy. This required some changes in c1_Runtime.cpp and deoptimization.cpp to handle these deopts and allocate MDOs (in C1). The counter increment is guarded by the make_not_entrant() call that guarantees that the increment happens only once per method state change.
Also fixed the comments in sweeper.cpp and indent in globals.hpp that I forgot to do the last time.

Thanks!
igor


On May 7, 2014, at 2:27 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> On 5/7/14 12:37 AM, Igor Veresov wrote:
>> Vladimir,
>> 
>> Thanks for the review!
>> Please find the reply inline.
>> 
>> igor
>> 
>> On May 6, 2014, at 5:05 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> I think we need to let SAP know about this change (counter code in C2) since it may affect their tiered compilation. It use the same Deoptimization::Reason_age.
>>> 
>> Oh, I didn?t know that. I?ll introduce another constant.
>> 
>>> Can you separate C1 trap_request newa code in a separate RFE and push it first?
>>> 
>> 
>> Do you think this is necessary? It so happens that the DeoptimizeStub was not used before this by any code. So the aging scheme is the only user of it so far.
> 
> I am fine to keep it in this fix but I can't review it. Ask Christian to look.
> 
>> 
>>> Can you add the field to MDO and not to MethodCounters? We doing this only for methods which were compiled already and have MDO. MethodCounters small size is important.
>> 
>> It was in MDO originally, unfortunately I have to make it work for pure C1 and we usually don?t allocate MDOs in that configuration. Although, we need to only allocate MDOs for methods with aging, a set of which may be would be smallish..  But MDOs are kind of big.. Would that be better?
> 
> I forgot about pure C1.
> Chris Plummer pointed me, for RTM changes, MethodCounters are allocated for all executed methods which may not be compiled. About 30% methods are executed.
> 
>> 
>>> Why the change in methodData.hpp and nmethod.cpp? '||' should be '&&' in nmethod::inc_decompile_count(), I think.
>> 
>> You?re right, for pure C1 that won?t work anyways, because there are no MDOs. I?ll remove these for now. I probably need another decompile counter to put a cap on the number of recompiles, see the idea below.
>> 
>>> In globals.hpp flags description indention is off.
>>> 
>> 
>> Fixed.
> 
> You moved it to opposite direction :) . Indention of all comments are the same in the file. They are not aligned to a flag's declaration line.
> 
>> 
>>> sweeper.cpp:
>>> 
>>> // The stack-scanning low-cost detection may not see the method was used (which can happen for
>>> 
>>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in the existing
> 
> You did not change above comments as I suggested.
> 
>>> 
>>> Why do you need to repeat? For small leaf nmethods (with no safepoint, for example) it could trigger continues recompilation:
>>> 
>>> +             if (time_since_reset > MinPassesBeforeFlush * 2) {
>>> +               // It's been long enough, we still haven't seen it on stack.
>>> +               // Try to flush it, but enable counters the next time.
>>> +               mc->reset_nmethod_age();
>>> 
>> 
>> That?s a good question. Before this change we would?ve recompiled warm methods continuously (given some code cache pressure), so the number of such cases is probably small. The options here with the code aging are:
>> - don?t ever again flush a method that we?ve seen deopt once;
>> - allow the flusher machinery to get rid of it if it becomes idle again.
>> 
>> Currently I decided to stick with the latter but also give the method twice the standard time initially to be noticed by the stack-walker. You are right that there is a problem for small methods. Technically there is always one safepoint in the epilog though, right? I?m good with either option. Vladimir, what are your thoughts on this? Albert, if you skimming through this, what do you think?
>> 
>> Here is an idea... We could count the number of decompiles for this particular reason and use it to scale the number of stack-walks we have to do before we flush the method again. For example we can wait MinPassesBeforeFlush * number_of_aging_deopts() stack-walks. Essentially this makes it unflushable in the limit - a combination of the two options above.
>> I?ll need to allocate an MDO or add another counter to methodCounters for that though, or pack a small value info method_age itself, at the expense of a slightly bigger code. And there is an MT problem, as usual, with counting the number of deopts.
> 
> As we discussed the check will be scaled by number of recompilation.
> 
> Thanks,
> Vladimir
> 
>> 
>> Here is the updated (with the changes addressed so far) webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/
>> 
>> Thanks,
>> igor
>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 5/5/14 7:44 PM, Igor Veresov wrote:
>>>> The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows:
>>>> 
>>>> 1. Initially a method is compiled as usual (no instrumentation, no overhead).
>>>> 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code.
>>>> 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter.
>>>> 4. The value of the counter is then used by the sweeper to determine is the method is in fact used.
>>>> 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again.
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>>>> 
>>>> Testing:
>>>> - jprt,
>>>> - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations.
>>>> 
>>>> igor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140508/babcee51/attachment.html>

From igor.veresov at oracle.com  Thu May  8 19:31:16 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 8 May 2014 12:31:16 -0700
Subject: [9] RFR(S): 8029343: CodeCache::allocate increments
	'_number_of_blobs' even if allocation fails.
In-Reply-To: <536B5BD4.9020205@oracle.com>
References: <53688ECC.5020308@oracle.com>
	<53689237.9090609@oracle.com>	<5368D922.8060600@oracle.com>
	<53692956.9060208@oracle.com> <536B5BD4.9020205@oracle.com>
Message-ID: <1216C2BE-7FC5-4D1C-A33F-AF936EB33F5B@oracle.com>

Yes, sure.

igor

On May 8, 2014, at 3:26 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Thank you Vladimir and Igor.
> 
> Can we push the changes?
> 
> Tobias
> 
> On 06.05.2014 20:26, Vladimir Kozlov wrote:
>> On 5/6/14 5:44 AM, Tobias Hartmann wrote:
>>> Hi Vladimir,
>>> 
>>> On 06.05.2014 09:41, Vladimir Kozlov wrote:
>>>> Parfait may complain about returning NULL and without guarantee.
>>>> Please, test.
>>> 
>>> I tested the implementation with parfait and no new defects showed up.
>> 
>> Okay.
>> 
>> Thanks,
>> Vladimir
>> 
>>> 
>>> Thanks,
>>> Tobias
>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>> On 5/6/14 12:27 AM, Tobias Hartmann wrote:
>>>>> Hi,
>>>>> 
>>>>> please review the following patch for bug 8029343.
>>>>> 
>>>>> *Problem:*
>>>>> (1) CodeCache::allocate(...) increments _number_of_blobs before the
>>>>> actual allocation is performed. In case the
>>>>> allocation fails the counter is set to a wrong value.
>>>>> (2) The guarantee(size >= 0, ...) is incorrect. Calling
>>>>> CodeCache::allocate(...) with size = 0 leads to a segmentation
>>>>> fault. Further, a guarantee is too strong here. We can simply return
>>>>> NULL at runtime if the size is <= 0.
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8029343
>>>>> 
>>>>> *Solution:*
>>>>> (1) The increment is moved after the allocation.
>>>>> (2) An assert is used instead of the guarantee and NULL is returned
>>>>> if size <= 0.
>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8029343/webrev.00/
>>>>> 
>>>>> Thanks,
>>>>> Tobias
>>> 
> 


From vladimir.kozlov at oracle.com  Fri May  9 01:28:43 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 08 May 2014 18:28:43 -0700
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
	<536978D0.7060901@oracle.com>
	<3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com>
	<536AA53A.7050408@oracle.com>
	<1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com>
Message-ID: <536C2F4B.6060405@oracle.com>

Looks good.

Thanks,
Vladimir

On 5/8/14 12:30 PM, Igor Veresov wrote:
> Alright, here is the update:
> http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/
>
> The change is that I added a trap counter in the MDO that is used to
> scale up the number of stack walks that are necessary for the tenured
> method to revert back to the standard flushing policy. This required
> some changes in c1_Runtime.cpp and deoptimization.cpp to handle these
> deopts and allocate MDOs (in C1). The counter increment is guarded by
> the make_not_entrant() call that guarantees that the increment happens
> only once per method state change.
> Also fixed the comments in sweeper.cpp and indent in globals.hpp that I
> forgot to do the last time.
>
> Thanks!
> igor
>
>
> On May 7, 2014, at 2:27 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> <mailto:vladimir.kozlov at oracle.com>> wrote:
>
>> On 5/7/14 12:37 AM, Igor Veresov wrote:
>>> Vladimir,
>>>
>>> Thanks for the review!
>>> Please find the reply inline.
>>>
>>> igor
>>>
>>> On May 6, 2014, at 5:05 PM, Vladimir Kozlov
>>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>
>>>> I think we need to let SAP know about this change (counter code in
>>>> C2) since it may affect their tiered compilation. It use the same
>>>> Deoptimization::Reason_age.
>>>>
>>> Oh, I didn?t know that. I?ll introduce another constant.
>>>
>>>> Can you separate C1 trap_request newa code in a separate RFE and
>>>> push it first?
>>>>
>>>
>>> Do you think this is necessary? It so happens that the DeoptimizeStub
>>> was not used before this by any code. So the aging scheme is the only
>>> user of it so far.
>>
>> I am fine to keep it in this fix but I can't review it. Ask Christian
>> to look.
>>
>>>
>>>> Can you add the field to MDO and not to MethodCounters? We doing
>>>> this only for methods which were compiled already and have MDO.
>>>> MethodCounters small size is important.
>>>
>>> It was in MDO originally, unfortunately I have to make it work for
>>> pure C1 and we usually don?t allocate MDOs in that configuration.
>>> Although, we need to only allocate MDOs for methods with aging, a set
>>> of which may be would be smallish..  But MDOs are kind of big.. Would
>>> that be better?
>>
>> I forgot about pure C1.
>> Chris Plummer pointed me, for RTM changes, MethodCounters are
>> allocated for all executed methods which may not be compiled. About
>> 30% methods are executed.
>>
>>>
>>>> Why the change in methodData.hpp and nmethod.cpp? '||' should be
>>>> '&&' in nmethod::inc_decompile_count(), I think.
>>>
>>> You?re right, for pure C1 that won?t work anyways, because there are
>>> no MDOs. I?ll remove these for now. I probably need another decompile
>>> counter to put a cap on the number of recompiles, see the idea below.
>>>
>>>> In globals.hpp flags description indention is off.
>>>>
>>>
>>> Fixed.
>>
>> You moved it to opposite direction :) . Indention of all comments are
>> the same in the file. They are not aligned to a flag's declaration line.
>>
>>>
>>>> sweeper.cpp:
>>>>
>>>> // The stack-scanning low-cost detection may not see the method was
>>>> used (which can happen for
>>>>
>>>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in
>>>> the existing
>>
>> You did not change above comments as I suggested.
>>
>>>>
>>>> Why do you need to repeat? For small leaf nmethods (with no
>>>> safepoint, for example) it could trigger continues recompilation:
>>>>
>>>> +             if (time_since_reset > MinPassesBeforeFlush * 2) {
>>>> +               // It's been long enough, we still haven't seen it
>>>> on stack.
>>>> +               // Try to flush it, but enable counters the next time.
>>>> +               mc->reset_nmethod_age();
>>>>
>>>
>>> That?s a good question. Before this change we would?ve recompiled
>>> warm methods continuously (given some code cache pressure), so the
>>> number of such cases is probably small. The options here with the
>>> code aging are:
>>> - don?t ever again flush a method that we?ve seen deopt once;
>>> - allow the flusher machinery to get rid of it if it becomes idle again.
>>>
>>> Currently I decided to stick with the latter but also give the method
>>> twice the standard time initially to be noticed by the stack-walker.
>>> You are right that there is a problem for small methods. Technically
>>> there is always one safepoint in the epilog though, right? I?m good
>>> with either option. Vladimir, what are your thoughts on this? Albert,
>>> if you skimming through this, what do you think?
>>>
>>> Here is an idea... We could count the number of decompiles for this
>>> particular reason and use it to scale the number of stack-walks we
>>> have to do before we flush the method again. For example we can wait
>>> MinPassesBeforeFlush * number_of_aging_deopts() stack-walks.
>>> Essentially this makes it unflushable in the limit - a combination of
>>> the two options above.
>>> I?ll need to allocate an MDO or add another counter to methodCounters
>>> for that though, or pack a small value info method_age itself, at the
>>> expense of a slightly bigger code. And there is an MT problem, as
>>> usual, with counting the number of deopts.
>>
>> As we discussed the check will be scaled by number of recompilation.
>>
>> Thanks,
>> Vladimir
>>
>>>
>>> Here is the updated (with the changes addressed so far) webrev:
>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/
>>>
>>> Thanks,
>>> igor
>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 5/5/14 7:44 PM, Igor Veresov wrote:
>>>>> The current implementation of the code cache flusher tries to
>>>>> determine the working set of methods by doing periodic stack walks
>>>>> during safepoints. Methods that are seen on the stack are
>>>>> considered to be used by the program and are excluded from the set
>>>>> of flush candidates. Such sampling is a great zero-overhead
>>>>> approach to collect the working set of super-hot methods without
>>>>> instrumentation. However it doesn?t work that good for flat
>>>>> profiles, which the test in the bug report happens to expose
>>>>> (thousands of methods calls sequentially one after another in the
>>>>> loop). The solution I ended up implementing uses conservative
>>>>> on-demand instrumentation to obtain information about the method
>>>>> usage. The algorithms is as follows:
>>>>>
>>>>> 1. Initially a method is compiled as usual (no instrumentation, no
>>>>> overhead).
>>>>> 2. When the sampling (stack-walking) scheme fails to detect
>>>>> activity we flush the method (again, as usual). However before the
>>>>> flush we set the age counter (an int added to MethodCounters) to a
>>>>> value that instructs the compilers to instrument the code.
>>>>> 3. If we ever request to compile this method again the aging code
>>>>> is inserted, which decrements the counter.
>>>>> 4. The value of the counter is then used by the sweeper to
>>>>> determine is the method is in fact used.
>>>>> 5. If the counter reaches zero before the sweeper is able examine
>>>>> and reset the counter we deopt and recompile the method without the
>>>>> counters, basically switching it back to use the sampling scheme again.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>>>>>
>>>>> Testing:
>>>>> - jprt,
>>>>> - aurora-perf No performance effects with the default code cache,
>>>>> since we have enough headroom and the flusher is not exercised that
>>>>> much. No statistically significant effects after warmup (for spec
>>>>> benchmarks) in stress mode (-XX:+StressCodeAging) either, that is
>>>>> if all methods are compiled initially with counters deopt and
>>>>> switch to sampling later after 100000 invocations.
>>>>>
>>>>> igor
>

From christian.thalinger at oracle.com  Fri May  9 02:25:18 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 8 May 2014 16:25:18 -1000
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <536C2F4B.6060405@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
	<536978D0.7060901@oracle.com>
	<3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com>
	<536AA53A.7050408@oracle.com>
	<1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com>
	<536C2F4B.6060405@oracle.com>
Message-ID: <C09A95AD-3B9C-4691-9170-26FD9454AED3@oracle.com>

src/share/vm/c1/c1_Runtime1.cpp
+   nmethod* nm = (nmethod*)caller_frame.cb();
+   assert(nm != NULL && nm->is_nmethod(), "Sanity check");
There is CodeBlob::as_nmethod_or_null().

The C1 code looks good.

On May 8, 2014, at 3:28 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Looks good.
> 
> Thanks,
> Vladimir
> 
> On 5/8/14 12:30 PM, Igor Veresov wrote:
>> Alright, here is the update:
>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/
>> 
>> The change is that I added a trap counter in the MDO that is used to
>> scale up the number of stack walks that are necessary for the tenured
>> method to revert back to the standard flushing policy. This required
>> some changes in c1_Runtime.cpp and deoptimization.cpp to handle these
>> deopts and allocate MDOs (in C1). The counter increment is guarded by
>> the make_not_entrant() call that guarantees that the increment happens
>> only once per method state change.
>> Also fixed the comments in sweeper.cpp and indent in globals.hpp that I
>> forgot to do the last time.
>> 
>> Thanks!
>> igor
>> 
>> 
>> On May 7, 2014, at 2:27 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
>> <mailto:vladimir.kozlov at oracle.com>> wrote:
>> 
>>> On 5/7/14 12:37 AM, Igor Veresov wrote:
>>>> Vladimir,
>>>> 
>>>> Thanks for the review!
>>>> Please find the reply inline.
>>>> 
>>>> igor
>>>> 
>>>> On May 6, 2014, at 5:05 PM, Vladimir Kozlov
>>>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>> 
>>>>> I think we need to let SAP know about this change (counter code in
>>>>> C2) since it may affect their tiered compilation. It use the same
>>>>> Deoptimization::Reason_age.
>>>>> 
>>>> Oh, I didn?t know that. I?ll introduce another constant.
>>>> 
>>>>> Can you separate C1 trap_request newa code in a separate RFE and
>>>>> push it first?
>>>>> 
>>>> 
>>>> Do you think this is necessary? It so happens that the DeoptimizeStub
>>>> was not used before this by any code. So the aging scheme is the only
>>>> user of it so far.
>>> 
>>> I am fine to keep it in this fix but I can't review it. Ask Christian
>>> to look.
>>> 
>>>> 
>>>>> Can you add the field to MDO and not to MethodCounters? We doing
>>>>> this only for methods which were compiled already and have MDO.
>>>>> MethodCounters small size is important.
>>>> 
>>>> It was in MDO originally, unfortunately I have to make it work for
>>>> pure C1 and we usually don?t allocate MDOs in that configuration.
>>>> Although, we need to only allocate MDOs for methods with aging, a set
>>>> of which may be would be smallish..  But MDOs are kind of big.. Would
>>>> that be better?
>>> 
>>> I forgot about pure C1.
>>> Chris Plummer pointed me, for RTM changes, MethodCounters are
>>> allocated for all executed methods which may not be compiled. About
>>> 30% methods are executed.
>>> 
>>>> 
>>>>> Why the change in methodData.hpp and nmethod.cpp? '||' should be
>>>>> '&&' in nmethod::inc_decompile_count(), I think.
>>>> 
>>>> You?re right, for pure C1 that won?t work anyways, because there are
>>>> no MDOs. I?ll remove these for now. I probably need another decompile
>>>> counter to put a cap on the number of recompiles, see the idea below.
>>>> 
>>>>> In globals.hpp flags description indention is off.
>>>>> 
>>>> 
>>>> Fixed.
>>> 
>>> You moved it to opposite direction :) . Indention of all comments are
>>> the same in the file. They are not aligned to a flag's declaration line.
>>> 
>>>> 
>>>>> sweeper.cpp:
>>>>> 
>>>>> // The stack-scanning low-cost detection may not see the method was
>>>>> used (which can happen for
>>>>> 
>>>>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in
>>>>> the existing
>>> 
>>> You did not change above comments as I suggested.
>>> 
>>>>> 
>>>>> Why do you need to repeat? For small leaf nmethods (with no
>>>>> safepoint, for example) it could trigger continues recompilation:
>>>>> 
>>>>> +             if (time_since_reset > MinPassesBeforeFlush * 2) {
>>>>> +               // It's been long enough, we still haven't seen it
>>>>> on stack.
>>>>> +               // Try to flush it, but enable counters the next time.
>>>>> +               mc->reset_nmethod_age();
>>>>> 
>>>> 
>>>> That?s a good question. Before this change we would?ve recompiled
>>>> warm methods continuously (given some code cache pressure), so the
>>>> number of such cases is probably small. The options here with the
>>>> code aging are:
>>>> - don?t ever again flush a method that we?ve seen deopt once;
>>>> - allow the flusher machinery to get rid of it if it becomes idle again.
>>>> 
>>>> Currently I decided to stick with the latter but also give the method
>>>> twice the standard time initially to be noticed by the stack-walker.
>>>> You are right that there is a problem for small methods. Technically
>>>> there is always one safepoint in the epilog though, right? I?m good
>>>> with either option. Vladimir, what are your thoughts on this? Albert,
>>>> if you skimming through this, what do you think?
>>>> 
>>>> Here is an idea... We could count the number of decompiles for this
>>>> particular reason and use it to scale the number of stack-walks we
>>>> have to do before we flush the method again. For example we can wait
>>>> MinPassesBeforeFlush * number_of_aging_deopts() stack-walks.
>>>> Essentially this makes it unflushable in the limit - a combination of
>>>> the two options above.
>>>> I?ll need to allocate an MDO or add another counter to methodCounters
>>>> for that though, or pack a small value info method_age itself, at the
>>>> expense of a slightly bigger code. And there is an MT problem, as
>>>> usual, with counting the number of deopts.
>>> 
>>> As we discussed the check will be scaled by number of recompilation.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>>> 
>>>> Here is the updated (with the changes addressed so far) webrev:
>>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/
>>>> 
>>>> Thanks,
>>>> igor
>>>> 
>>>>> Thanks,
>>>>> Vladimir
>>>>> 
>>>>> On 5/5/14 7:44 PM, Igor Veresov wrote:
>>>>>> The current implementation of the code cache flusher tries to
>>>>>> determine the working set of methods by doing periodic stack walks
>>>>>> during safepoints. Methods that are seen on the stack are
>>>>>> considered to be used by the program and are excluded from the set
>>>>>> of flush candidates. Such sampling is a great zero-overhead
>>>>>> approach to collect the working set of super-hot methods without
>>>>>> instrumentation. However it doesn?t work that good for flat
>>>>>> profiles, which the test in the bug report happens to expose
>>>>>> (thousands of methods calls sequentially one after another in the
>>>>>> loop). The solution I ended up implementing uses conservative
>>>>>> on-demand instrumentation to obtain information about the method
>>>>>> usage. The algorithms is as follows:
>>>>>> 
>>>>>> 1. Initially a method is compiled as usual (no instrumentation, no
>>>>>> overhead).
>>>>>> 2. When the sampling (stack-walking) scheme fails to detect
>>>>>> activity we flush the method (again, as usual). However before the
>>>>>> flush we set the age counter (an int added to MethodCounters) to a
>>>>>> value that instructs the compilers to instrument the code.
>>>>>> 3. If we ever request to compile this method again the aging code
>>>>>> is inserted, which decrements the counter.
>>>>>> 4. The value of the counter is then used by the sweeper to
>>>>>> determine is the method is in fact used.
>>>>>> 5. If the counter reaches zero before the sweeper is able examine
>>>>>> and reset the counter we deopt and recompile the method without the
>>>>>> counters, basically switching it back to use the sampling scheme again.
>>>>>> 
>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>>>>>> 
>>>>>> Testing:
>>>>>> - jprt,
>>>>>> - aurora-perf No performance effects with the default code cache,
>>>>>> since we have enough headroom and the flusher is not exercised that
>>>>>> much. No statistically significant effects after warmup (for spec
>>>>>> benchmarks) in stress mode (-XX:+StressCodeAging) either, that is
>>>>>> if all methods are compiled initially with counters deopt and
>>>>>> switch to sampling later after 100000 invocations.
>>>>>> 
>>>>>> igor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140508/745353bb/attachment.html>

From igor.veresov at oracle.com  Fri May  9 02:35:15 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 8 May 2014 19:35:15 -0700
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <536C2F4B.6060405@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
	<536978D0.7060901@oracle.com>
	<3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com>
	<536AA53A.7050408@oracle.com>
	<1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com>
	<536C2F4B.6060405@oracle.com>
Message-ID: <0487BADD-BF7A-4F80-871A-3ABF3ECECA35@oracle.com>

Thanks, Vladimir!

igor

On May 8, 2014, at 6:28 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Looks good.
> 
> Thanks,
> Vladimir
> 
> On 5/8/14 12:30 PM, Igor Veresov wrote:
>> Alright, here is the update:
>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/
>> 
>> The change is that I added a trap counter in the MDO that is used to
>> scale up the number of stack walks that are necessary for the tenured
>> method to revert back to the standard flushing policy. This required
>> some changes in c1_Runtime.cpp and deoptimization.cpp to handle these
>> deopts and allocate MDOs (in C1). The counter increment is guarded by
>> the make_not_entrant() call that guarantees that the increment happens
>> only once per method state change.
>> Also fixed the comments in sweeper.cpp and indent in globals.hpp that I
>> forgot to do the last time.
>> 
>> Thanks!
>> igor
>> 
>> 
>> On May 7, 2014, at 2:27 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
>> <mailto:vladimir.kozlov at oracle.com>> wrote:
>> 
>>> On 5/7/14 12:37 AM, Igor Veresov wrote:
>>>> Vladimir,
>>>> 
>>>> Thanks for the review!
>>>> Please find the reply inline.
>>>> 
>>>> igor
>>>> 
>>>> On May 6, 2014, at 5:05 PM, Vladimir Kozlov
>>>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>> 
>>>>> I think we need to let SAP know about this change (counter code in
>>>>> C2) since it may affect their tiered compilation. It use the same
>>>>> Deoptimization::Reason_age.
>>>>> 
>>>> Oh, I didn?t know that. I?ll introduce another constant.
>>>> 
>>>>> Can you separate C1 trap_request newa code in a separate RFE and
>>>>> push it first?
>>>>> 
>>>> 
>>>> Do you think this is necessary? It so happens that the DeoptimizeStub
>>>> was not used before this by any code. So the aging scheme is the only
>>>> user of it so far.
>>> 
>>> I am fine to keep it in this fix but I can't review it. Ask Christian
>>> to look.
>>> 
>>>> 
>>>>> Can you add the field to MDO and not to MethodCounters? We doing
>>>>> this only for methods which were compiled already and have MDO.
>>>>> MethodCounters small size is important.
>>>> 
>>>> It was in MDO originally, unfortunately I have to make it work for
>>>> pure C1 and we usually don?t allocate MDOs in that configuration.
>>>> Although, we need to only allocate MDOs for methods with aging, a set
>>>> of which may be would be smallish..  But MDOs are kind of big.. Would
>>>> that be better?
>>> 
>>> I forgot about pure C1.
>>> Chris Plummer pointed me, for RTM changes, MethodCounters are
>>> allocated for all executed methods which may not be compiled. About
>>> 30% methods are executed.
>>> 
>>>> 
>>>>> Why the change in methodData.hpp and nmethod.cpp? '||' should be
>>>>> '&&' in nmethod::inc_decompile_count(), I think.
>>>> 
>>>> You?re right, for pure C1 that won?t work anyways, because there are
>>>> no MDOs. I?ll remove these for now. I probably need another decompile
>>>> counter to put a cap on the number of recompiles, see the idea below.
>>>> 
>>>>> In globals.hpp flags description indention is off.
>>>>> 
>>>> 
>>>> Fixed.
>>> 
>>> You moved it to opposite direction :) . Indention of all comments are
>>> the same in the file. They are not aligned to a flag's declaration line.
>>> 
>>>> 
>>>>> sweeper.cpp:
>>>>> 
>>>>> // The stack-scanning low-cost detection may not see the method was
>>>>> used (which can happen for
>>>>> 
>>>>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in
>>>>> the existing
>>> 
>>> You did not change above comments as I suggested.
>>> 
>>>>> 
>>>>> Why do you need to repeat? For small leaf nmethods (with no
>>>>> safepoint, for example) it could trigger continues recompilation:
>>>>> 
>>>>> +             if (time_since_reset > MinPassesBeforeFlush * 2) {
>>>>> +               // It's been long enough, we still haven't seen it
>>>>> on stack.
>>>>> +               // Try to flush it, but enable counters the next time.
>>>>> +               mc->reset_nmethod_age();
>>>>> 
>>>> 
>>>> That?s a good question. Before this change we would?ve recompiled
>>>> warm methods continuously (given some code cache pressure), so the
>>>> number of such cases is probably small. The options here with the
>>>> code aging are:
>>>> - don?t ever again flush a method that we?ve seen deopt once;
>>>> - allow the flusher machinery to get rid of it if it becomes idle again.
>>>> 
>>>> Currently I decided to stick with the latter but also give the method
>>>> twice the standard time initially to be noticed by the stack-walker.
>>>> You are right that there is a problem for small methods. Technically
>>>> there is always one safepoint in the epilog though, right? I?m good
>>>> with either option. Vladimir, what are your thoughts on this? Albert,
>>>> if you skimming through this, what do you think?
>>>> 
>>>> Here is an idea... We could count the number of decompiles for this
>>>> particular reason and use it to scale the number of stack-walks we
>>>> have to do before we flush the method again. For example we can wait
>>>> MinPassesBeforeFlush * number_of_aging_deopts() stack-walks.
>>>> Essentially this makes it unflushable in the limit - a combination of
>>>> the two options above.
>>>> I?ll need to allocate an MDO or add another counter to methodCounters
>>>> for that though, or pack a small value info method_age itself, at the
>>>> expense of a slightly bigger code. And there is an MT problem, as
>>>> usual, with counting the number of deopts.
>>> 
>>> As we discussed the check will be scaled by number of recompilation.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>>> 
>>>> Here is the updated (with the changes addressed so far) webrev:
>>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/
>>>> 
>>>> Thanks,
>>>> igor
>>>> 
>>>>> Thanks,
>>>>> Vladimir
>>>>> 
>>>>> On 5/5/14 7:44 PM, Igor Veresov wrote:
>>>>>> The current implementation of the code cache flusher tries to
>>>>>> determine the working set of methods by doing periodic stack walks
>>>>>> during safepoints. Methods that are seen on the stack are
>>>>>> considered to be used by the program and are excluded from the set
>>>>>> of flush candidates. Such sampling is a great zero-overhead
>>>>>> approach to collect the working set of super-hot methods without
>>>>>> instrumentation. However it doesn?t work that good for flat
>>>>>> profiles, which the test in the bug report happens to expose
>>>>>> (thousands of methods calls sequentially one after another in the
>>>>>> loop). The solution I ended up implementing uses conservative
>>>>>> on-demand instrumentation to obtain information about the method
>>>>>> usage. The algorithms is as follows:
>>>>>> 
>>>>>> 1. Initially a method is compiled as usual (no instrumentation, no
>>>>>> overhead).
>>>>>> 2. When the sampling (stack-walking) scheme fails to detect
>>>>>> activity we flush the method (again, as usual). However before the
>>>>>> flush we set the age counter (an int added to MethodCounters) to a
>>>>>> value that instructs the compilers to instrument the code.
>>>>>> 3. If we ever request to compile this method again the aging code
>>>>>> is inserted, which decrements the counter.
>>>>>> 4. The value of the counter is then used by the sweeper to
>>>>>> determine is the method is in fact used.
>>>>>> 5. If the counter reaches zero before the sweeper is able examine
>>>>>> and reset the counter we deopt and recompile the method without the
>>>>>> counters, basically switching it back to use the sampling scheme again.
>>>>>> 
>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>>>>>> 
>>>>>> Testing:
>>>>>> - jprt,
>>>>>> - aurora-perf No performance effects with the default code cache,
>>>>>> since we have enough headroom and the flusher is not exercised that
>>>>>> much. No statistically significant effects after warmup (for spec
>>>>>> benchmarks) in stress mode (-XX:+StressCodeAging) either, that is
>>>>>> if all methods are compiled initially with counters deopt and
>>>>>> switch to sampling later after 100000 invocations.
>>>>>> 
>>>>>> igor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140508/e0a04ab8/attachment-0001.html>

From igor.veresov at oracle.com  Fri May  9 02:37:02 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 8 May 2014 19:37:02 -0700
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <C09A95AD-3B9C-4691-9170-26FD9454AED3@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
	<536978D0.7060901@oracle.com>
	<3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com>
	<536AA53A.7050408@oracle.com>
	<1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com>
	<536C2F4B.6060405@oracle.com>
	<C09A95AD-3B9C-4691-9170-26FD9454AED3@oracle.com>
Message-ID: <8E2D4585-3D2B-470C-A76D-E70A96AE87EB@oracle.com>

Thanks, Chris!

Alright, thanks for the hint: http://cr.openjdk.java.net/~iveresov/8032463/webrev.03/

igor

On May 8, 2014, at 7:25 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> src/share/vm/c1/c1_Runtime1.cpp
> +   nmethod* nm = (nmethod*)caller_frame.cb();
> +   assert(nm != NULL && nm->is_nmethod(), "Sanity check");
> There is CodeBlob::as_nmethod_or_null().
> 
> The C1 code looks good.
> 
> On May 8, 2014, at 3:28 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>> Looks good.
>> 
>> Thanks,
>> Vladimir
>> 
>> On 5/8/14 12:30 PM, Igor Veresov wrote:
>>> Alright, here is the update:
>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/
>>> 
>>> The change is that I added a trap counter in the MDO that is used to
>>> scale up the number of stack walks that are necessary for the tenured
>>> method to revert back to the standard flushing policy. This required
>>> some changes in c1_Runtime.cpp and deoptimization.cpp to handle these
>>> deopts and allocate MDOs (in C1). The counter increment is guarded by
>>> the make_not_entrant() call that guarantees that the increment happens
>>> only once per method state change.
>>> Also fixed the comments in sweeper.cpp and indent in globals.hpp that I
>>> forgot to do the last time.
>>> 
>>> Thanks!
>>> igor
>>> 
>>> 
>>> On May 7, 2014, at 2:27 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
>>> <mailto:vladimir.kozlov at oracle.com>> wrote:
>>> 
>>>> On 5/7/14 12:37 AM, Igor Veresov wrote:
>>>>> Vladimir,
>>>>> 
>>>>> Thanks for the review!
>>>>> Please find the reply inline.
>>>>> 
>>>>> igor
>>>>> 
>>>>> On May 6, 2014, at 5:05 PM, Vladimir Kozlov
>>>>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>>> 
>>>>>> I think we need to let SAP know about this change (counter code in
>>>>>> C2) since it may affect their tiered compilation. It use the same
>>>>>> Deoptimization::Reason_age.
>>>>>> 
>>>>> Oh, I didn?t know that. I?ll introduce another constant.
>>>>> 
>>>>>> Can you separate C1 trap_request newa code in a separate RFE and
>>>>>> push it first?
>>>>>> 
>>>>> 
>>>>> Do you think this is necessary? It so happens that the DeoptimizeStub
>>>>> was not used before this by any code. So the aging scheme is the only
>>>>> user of it so far.
>>>> 
>>>> I am fine to keep it in this fix but I can't review it. Ask Christian
>>>> to look.
>>>> 
>>>>> 
>>>>>> Can you add the field to MDO and not to MethodCounters? We doing
>>>>>> this only for methods which were compiled already and have MDO.
>>>>>> MethodCounters small size is important.
>>>>> 
>>>>> It was in MDO originally, unfortunately I have to make it work for
>>>>> pure C1 and we usually don?t allocate MDOs in that configuration.
>>>>> Although, we need to only allocate MDOs for methods with aging, a set
>>>>> of which may be would be smallish..  But MDOs are kind of big.. Would
>>>>> that be better?
>>>> 
>>>> I forgot about pure C1.
>>>> Chris Plummer pointed me, for RTM changes, MethodCounters are
>>>> allocated for all executed methods which may not be compiled. About
>>>> 30% methods are executed.
>>>> 
>>>>> 
>>>>>> Why the change in methodData.hpp and nmethod.cpp? '||' should be
>>>>>> '&&' in nmethod::inc_decompile_count(), I think.
>>>>> 
>>>>> You?re right, for pure C1 that won?t work anyways, because there are
>>>>> no MDOs. I?ll remove these for now. I probably need another decompile
>>>>> counter to put a cap on the number of recompiles, see the idea below.
>>>>> 
>>>>>> In globals.hpp flags description indention is off.
>>>>>> 
>>>>> 
>>>>> Fixed.
>>>> 
>>>> You moved it to opposite direction :) . Indention of all comments are
>>>> the same in the file. They are not aligned to a flag's declaration line.
>>>> 
>>>>> 
>>>>>> sweeper.cpp:
>>>>>> 
>>>>>> // The stack-scanning low-cost detection may not see the method was
>>>>>> used (which can happen for
>>>>>> 
>>>>>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in
>>>>>> the existing
>>>> 
>>>> You did not change above comments as I suggested.
>>>> 
>>>>>> 
>>>>>> Why do you need to repeat? For small leaf nmethods (with no
>>>>>> safepoint, for example) it could trigger continues recompilation:
>>>>>> 
>>>>>> +             if (time_since_reset > MinPassesBeforeFlush * 2) {
>>>>>> +               // It's been long enough, we still haven't seen it
>>>>>> on stack.
>>>>>> +               // Try to flush it, but enable counters the next time.
>>>>>> +               mc->reset_nmethod_age();
>>>>>> 
>>>>> 
>>>>> That?s a good question. Before this change we would?ve recompiled
>>>>> warm methods continuously (given some code cache pressure), so the
>>>>> number of such cases is probably small. The options here with the
>>>>> code aging are:
>>>>> - don?t ever again flush a method that we?ve seen deopt once;
>>>>> - allow the flusher machinery to get rid of it if it becomes idle again.
>>>>> 
>>>>> Currently I decided to stick with the latter but also give the method
>>>>> twice the standard time initially to be noticed by the stack-walker.
>>>>> You are right that there is a problem for small methods. Technically
>>>>> there is always one safepoint in the epilog though, right? I?m good
>>>>> with either option. Vladimir, what are your thoughts on this? Albert,
>>>>> if you skimming through this, what do you think?
>>>>> 
>>>>> Here is an idea... We could count the number of decompiles for this
>>>>> particular reason and use it to scale the number of stack-walks we
>>>>> have to do before we flush the method again. For example we can wait
>>>>> MinPassesBeforeFlush * number_of_aging_deopts() stack-walks.
>>>>> Essentially this makes it unflushable in the limit - a combination of
>>>>> the two options above.
>>>>> I?ll need to allocate an MDO or add another counter to methodCounters
>>>>> for that though, or pack a small value info method_age itself, at the
>>>>> expense of a slightly bigger code. And there is an MT problem, as
>>>>> usual, with counting the number of deopts.
>>>> 
>>>> As we discussed the check will be scaled by number of recompilation.
>>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>>> 
>>>>> Here is the updated (with the changes addressed so far) webrev:
>>>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/
>>>>> 
>>>>> Thanks,
>>>>> igor
>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>> 
>>>>>> On 5/5/14 7:44 PM, Igor Veresov wrote:
>>>>>>> The current implementation of the code cache flusher tries to
>>>>>>> determine the working set of methods by doing periodic stack walks
>>>>>>> during safepoints. Methods that are seen on the stack are
>>>>>>> considered to be used by the program and are excluded from the set
>>>>>>> of flush candidates. Such sampling is a great zero-overhead
>>>>>>> approach to collect the working set of super-hot methods without
>>>>>>> instrumentation. However it doesn?t work that good for flat
>>>>>>> profiles, which the test in the bug report happens to expose
>>>>>>> (thousands of methods calls sequentially one after another in the
>>>>>>> loop). The solution I ended up implementing uses conservative
>>>>>>> on-demand instrumentation to obtain information about the method
>>>>>>> usage. The algorithms is as follows:
>>>>>>> 
>>>>>>> 1. Initially a method is compiled as usual (no instrumentation, no
>>>>>>> overhead).
>>>>>>> 2. When the sampling (stack-walking) scheme fails to detect
>>>>>>> activity we flush the method (again, as usual). However before the
>>>>>>> flush we set the age counter (an int added to MethodCounters) to a
>>>>>>> value that instructs the compilers to instrument the code.
>>>>>>> 3. If we ever request to compile this method again the aging code
>>>>>>> is inserted, which decrements the counter.
>>>>>>> 4. The value of the counter is then used by the sweeper to
>>>>>>> determine is the method is in fact used.
>>>>>>> 5. If the counter reaches zero before the sweeper is able examine
>>>>>>> and reset the counter we deopt and recompile the method without the
>>>>>>> counters, basically switching it back to use the sampling scheme again.
>>>>>>> 
>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>>>>>>> 
>>>>>>> Testing:
>>>>>>> - jprt,
>>>>>>> - aurora-perf No performance effects with the default code cache,
>>>>>>> since we have enough headroom and the flusher is not exercised that
>>>>>>> much. No statistically significant effects after warmup (for spec
>>>>>>> benchmarks) in stress mode (-XX:+StressCodeAging) either, that is
>>>>>>> if all methods are compiled initially with counters deopt and
>>>>>>> switch to sampling later after 100000 invocations.
>>>>>>> 
>>>>>>> igor
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140508/6e6562b1/attachment.html>

From christian.thalinger at oracle.com  Fri May  9 02:41:51 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 8 May 2014 16:41:51 -1000
Subject: Adding read barriers to the interpreter
In-Reply-To: <CAByMnGv9Ejj=Ge4X1Eg6Teo585zDpXi274UxZxpKn7qzve-eNA@mail.gmail.com>
References: <CAByMnGskLS-0JxaeTdtjg+LwYk3aDOUEbYVqoPRVZK-9xPRbAQ@mail.gmail.com>
	<CAByMnGv9Ejj=Ge4X1Eg6Teo585zDpXi274UxZxpKn7qzve-eNA@mail.gmail.com>
Message-ID: <B0C439BD-F667-4935-BFD2-E31DD0DA34C2@oracle.com>

Look at the get and putfield code in TemplateTable.  For volatile fields we already emit a memory barrier.

On May 7, 2014, at 3:17 PM, Meisam Fathi <meisam.fathi at gmail.com> wrote:

> Hi,
> 
> I nee to add read barriers before putfield and get field instructions in the hotspot interpreter.
> Would somebody direct me to the point in the code where I should add read or write barriers?
> 
> Thanks,
> Meisam
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140508/afd56666/attachment.html>

From christian.thalinger at oracle.com  Fri May  9 02:43:05 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 8 May 2014 16:43:05 -1000
Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with
	DeoptimizeALot
In-Reply-To: <8E2D4585-3D2B-470C-A76D-E70A96AE87EB@oracle.com>
References: <FCCBA6BC-87BF-4A9C-AF30-BC5E06CFBC7B@oracle.com>
	<536978D0.7060901@oracle.com>
	<3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com>
	<536AA53A.7050408@oracle.com>
	<1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com>
	<536C2F4B.6060405@oracle.com>
	<C09A95AD-3B9C-4691-9170-26FD9454AED3@oracle.com>
	<8E2D4585-3D2B-470C-A76D-E70A96AE87EB@oracle.com>
Message-ID: <E62A193A-C5C1-4422-878A-30596882E4D2@oracle.com>

Good.

On May 8, 2014, at 4:37 PM, Igor Veresov <igor.veresov at oracle.com> wrote:

> Thanks, Chris!
> 
> Alright, thanks for the hint: http://cr.openjdk.java.net/~iveresov/8032463/webrev.03/
> 
> igor
> 
> On May 8, 2014, at 7:25 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> src/share/vm/c1/c1_Runtime1.cpp
>> +   nmethod* nm = (nmethod*)caller_frame.cb();
>> +   assert(nm != NULL && nm->is_nmethod(), "Sanity check");
>> There is CodeBlob::as_nmethod_or_null().
>> 
>> The C1 code looks good.
>> 
>> On May 8, 2014, at 3:28 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> Looks good.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 5/8/14 12:30 PM, Igor Veresov wrote:
>>>> Alright, here is the update:
>>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/
>>>> 
>>>> The change is that I added a trap counter in the MDO that is used to
>>>> scale up the number of stack walks that are necessary for the tenured
>>>> method to revert back to the standard flushing policy. This required
>>>> some changes in c1_Runtime.cpp and deoptimization.cpp to handle these
>>>> deopts and allocate MDOs (in C1). The counter increment is guarded by
>>>> the make_not_entrant() call that guarantees that the increment happens
>>>> only once per method state change.
>>>> Also fixed the comments in sweeper.cpp and indent in globals.hpp that I
>>>> forgot to do the last time.
>>>> 
>>>> Thanks!
>>>> igor
>>>> 
>>>> 
>>>> On May 7, 2014, at 2:27 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
>>>> <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>> 
>>>>> On 5/7/14 12:37 AM, Igor Veresov wrote:
>>>>>> Vladimir,
>>>>>> 
>>>>>> Thanks for the review!
>>>>>> Please find the reply inline.
>>>>>> 
>>>>>> igor
>>>>>> 
>>>>>> On May 6, 2014, at 5:05 PM, Vladimir Kozlov
>>>>>> <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>>>> 
>>>>>>> I think we need to let SAP know about this change (counter code in
>>>>>>> C2) since it may affect their tiered compilation. It use the same
>>>>>>> Deoptimization::Reason_age.
>>>>>>> 
>>>>>> Oh, I didn?t know that. I?ll introduce another constant.
>>>>>> 
>>>>>>> Can you separate C1 trap_request newa code in a separate RFE and
>>>>>>> push it first?
>>>>>>> 
>>>>>> 
>>>>>> Do you think this is necessary? It so happens that the DeoptimizeStub
>>>>>> was not used before this by any code. So the aging scheme is the only
>>>>>> user of it so far.
>>>>> 
>>>>> I am fine to keep it in this fix but I can't review it. Ask Christian
>>>>> to look.
>>>>> 
>>>>>> 
>>>>>>> Can you add the field to MDO and not to MethodCounters? We doing
>>>>>>> this only for methods which were compiled already and have MDO.
>>>>>>> MethodCounters small size is important.
>>>>>> 
>>>>>> It was in MDO originally, unfortunately I have to make it work for
>>>>>> pure C1 and we usually don?t allocate MDOs in that configuration.
>>>>>> Although, we need to only allocate MDOs for methods with aging, a set
>>>>>> of which may be would be smallish..  But MDOs are kind of big.. Would
>>>>>> that be better?
>>>>> 
>>>>> I forgot about pure C1.
>>>>> Chris Plummer pointed me, for RTM changes, MethodCounters are
>>>>> allocated for all executed methods which may not be compiled. About
>>>>> 30% methods are executed.
>>>>> 
>>>>>> 
>>>>>>> Why the change in methodData.hpp and nmethod.cpp? '||' should be
>>>>>>> '&&' in nmethod::inc_decompile_count(), I think.
>>>>>> 
>>>>>> You?re right, for pure C1 that won?t work anyways, because there are
>>>>>> no MDOs. I?ll remove these for now. I probably need another decompile
>>>>>> counter to put a cap on the number of recompiles, see the idea below.
>>>>>> 
>>>>>>> In globals.hpp flags description indention is off.
>>>>>>> 
>>>>>> 
>>>>>> Fixed.
>>>>> 
>>>>> You moved it to opposite direction :) . Indention of all comments are
>>>>> the same in the file. They are not aligned to a flag's declaration line.
>>>>> 
>>>>>> 
>>>>>>> sweeper.cpp:
>>>>>>> 
>>>>>>> // The stack-scanning low-cost detection may not see the method was
>>>>>>> used (which can happen for
>>>>>>> 
>>>>>>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in
>>>>>>> the existing
>>>>> 
>>>>> You did not change above comments as I suggested.
>>>>> 
>>>>>>> 
>>>>>>> Why do you need to repeat? For small leaf nmethods (with no
>>>>>>> safepoint, for example) it could trigger continues recompilation:
>>>>>>> 
>>>>>>> +             if (time_since_reset > MinPassesBeforeFlush * 2) {
>>>>>>> +               // It's been long enough, we still haven't seen it
>>>>>>> on stack.
>>>>>>> +               // Try to flush it, but enable counters the next time.
>>>>>>> +               mc->reset_nmethod_age();
>>>>>>> 
>>>>>> 
>>>>>> That?s a good question. Before this change we would?ve recompiled
>>>>>> warm methods continuously (given some code cache pressure), so the
>>>>>> number of such cases is probably small. The options here with the
>>>>>> code aging are:
>>>>>> - don?t ever again flush a method that we?ve seen deopt once;
>>>>>> - allow the flusher machinery to get rid of it if it becomes idle again.
>>>>>> 
>>>>>> Currently I decided to stick with the latter but also give the method
>>>>>> twice the standard time initially to be noticed by the stack-walker.
>>>>>> You are right that there is a problem for small methods. Technically
>>>>>> there is always one safepoint in the epilog though, right? I?m good
>>>>>> with either option. Vladimir, what are your thoughts on this? Albert,
>>>>>> if you skimming through this, what do you think?
>>>>>> 
>>>>>> Here is an idea... We could count the number of decompiles for this
>>>>>> particular reason and use it to scale the number of stack-walks we
>>>>>> have to do before we flush the method again. For example we can wait
>>>>>> MinPassesBeforeFlush * number_of_aging_deopts() stack-walks.
>>>>>> Essentially this makes it unflushable in the limit - a combination of
>>>>>> the two options above.
>>>>>> I?ll need to allocate an MDO or add another counter to methodCounters
>>>>>> for that though, or pack a small value info method_age itself, at the
>>>>>> expense of a slightly bigger code. And there is an MT problem, as
>>>>>> usual, with counting the number of deopts.
>>>>> 
>>>>> As we discussed the check will be scaled by number of recompilation.
>>>>> 
>>>>> Thanks,
>>>>> Vladimir
>>>>> 
>>>>>> 
>>>>>> Here is the updated (with the changes addressed so far) webrev:
>>>>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/
>>>>>> 
>>>>>> Thanks,
>>>>>> igor
>>>>>> 
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>> 
>>>>>>> On 5/5/14 7:44 PM, Igor Veresov wrote:
>>>>>>>> The current implementation of the code cache flusher tries to
>>>>>>>> determine the working set of methods by doing periodic stack walks
>>>>>>>> during safepoints. Methods that are seen on the stack are
>>>>>>>> considered to be used by the program and are excluded from the set
>>>>>>>> of flush candidates. Such sampling is a great zero-overhead
>>>>>>>> approach to collect the working set of super-hot methods without
>>>>>>>> instrumentation. However it doesn?t work that good for flat
>>>>>>>> profiles, which the test in the bug report happens to expose
>>>>>>>> (thousands of methods calls sequentially one after another in the
>>>>>>>> loop). The solution I ended up implementing uses conservative
>>>>>>>> on-demand instrumentation to obtain information about the method
>>>>>>>> usage. The algorithms is as follows:
>>>>>>>> 
>>>>>>>> 1. Initially a method is compiled as usual (no instrumentation, no
>>>>>>>> overhead).
>>>>>>>> 2. When the sampling (stack-walking) scheme fails to detect
>>>>>>>> activity we flush the method (again, as usual). However before the
>>>>>>>> flush we set the age counter (an int added to MethodCounters) to a
>>>>>>>> value that instructs the compilers to instrument the code.
>>>>>>>> 3. If we ever request to compile this method again the aging code
>>>>>>>> is inserted, which decrements the counter.
>>>>>>>> 4. The value of the counter is then used by the sweeper to
>>>>>>>> determine is the method is in fact used.
>>>>>>>> 5. If the counter reaches zero before the sweeper is able examine
>>>>>>>> and reset the counter we deopt and recompile the method without the
>>>>>>>> counters, basically switching it back to use the sampling scheme again.
>>>>>>>> 
>>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/
>>>>>>>> 
>>>>>>>> Testing:
>>>>>>>> - jprt,
>>>>>>>> - aurora-perf No performance effects with the default code cache,
>>>>>>>> since we have enough headroom and the flusher is not exercised that
>>>>>>>> much. No statistically significant effects after warmup (for spec
>>>>>>>> benchmarks) in stress mode (-XX:+StressCodeAging) either, that is
>>>>>>>> if all methods are compiled initially with counters deopt and
>>>>>>>> switch to sampling later after 100000 invocations.
>>>>>>>> 
>>>>>>>> igor
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140508/6179c43b/attachment-0001.html>

From tobias.hartmann at oracle.com  Fri May  9 06:37:34 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 09 May 2014 08:37:34 +0200
Subject: [9] RFR(S): 8021770: BackEdgeThreshold option is no longer used and
	should be removed
Message-ID: <536C77AE.9040104@oracle.com>

Hi,

please review the following patch for 8021770. The corresponding CCC 
request is approved.

The BackEdgeThreshold option is removed because it is no longer used.

Bug: https://bugs.openjdk.java.net/browse/JDK-8021770
Webrev: http://cr.openjdk.java.net/~anoll/8021770/webrev.00/

Thanks,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140509/e17943cc/attachment.html>

From rkennke at redhat.com  Fri May  9 07:37:54 2014
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 09 May 2014 09:37:54 +0200
Subject: Adding read barriers to the interpreter
In-Reply-To: <CAByMnGv9Ejj=Ge4X1Eg6Teo585zDpXi274UxZxpKn7qzve-eNA@mail.gmail.com>
References: <CAByMnGskLS-0JxaeTdtjg+LwYk3aDOUEbYVqoPRVZK-9xPRbAQ@mail.gmail.com>
	<CAByMnGv9Ejj=Ge4X1Eg6Teo585zDpXi274UxZxpKn7qzve-eNA@mail.gmail.com>
Message-ID: <1399621074.13134.2.camel@localhost.localdomain>

Hi Meisam,

The Shenandoah GC currently uses read barriers on field and array
access. You could check out the code and study it:

http://icedtea.classpath.org/shenandoah/

Search for 'resolve_oop' (the runtime read barriers) and
compile_resolve_oop (the barrier that is compiled in by the interpreter
and C1 compiler). C2 barriers is currently under development.

Best regards,
Roman

Am Mittwoch, den 07.05.2014, 21:17 -0400 schrieb Meisam Fathi:
> Hi,
> 
> I nee to add read barriers before putfield and get field instructions
> in the hotspot interpreter.
> Would somebody direct me to the point in the code where I should add
> read or write barriers?
> 
> Thanks,
> Meisam
> 



From aph at redhat.com  Fri May  9 08:29:31 2014
From: aph at redhat.com (Andrew Haley)
Date: Fri, 09 May 2014 09:29:31 +0100
Subject: Unsafe for array access
In-Reply-To: <536A5C3F.1070005@oracle.com>
References: <12C1134A-D491-4A59-ACF4-F6E2C10DA112@oracle.com>	<536A193C.7020405@cs.oswego.edu>	<F5A5CA0F-DCA2-4CDD-8B2D-48F193717C53@oracle.com>
	<536A5C3F.1070005@oracle.com>
Message-ID: <536C91EB.9090907@redhat.com>

On 05/07/2014 05:15 PM, Vladimir Kozlov wrote:
> Note, we do convert some user's bound check to array's range check. The example is Integer::valueOf():
> 
>      public static Integer valueOf(int i) {
>          if (i >= IntegerCache.low && i <= IntegerCache.high)
>              return IntegerCache.cache[i + (-IntegerCache.low)];
>          return new Integer(i);
>      }
> 
> The check is converted to ((i-IntegerCache.low) u< IntegerCache.length)

Did you mean

((i-IntegerCache.low) u< IntegerCache.high)

?


 and removed as duplicate of the generated range
> check for the following load.
> 
> length = (high - low) + 1
> 
> Vladimir
> 
> On 5/7/14 8:56 AM, John Rose wrote:
>>> On May 7, 2014, at 4:30 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>>
>>>
>>> Relatedly, it might be be nice to have an intrinsic boundsCheck(array, index)
>>> that could be used in such cases that implemented using the more efficient
>>> (using C): (unsigned)index >= (unsigned)array.length, plus relied on more
>>> efficient VM throw mechanics on failure.
>>
>> We need an intrinsic like this for Arrays 2.0. Might as well do it now, since we have an immediate application.
>>
>> Counterpoint:  optimizer can and should generate similar code for plain user written range tests.
>>
>> Advice:  Do both, and the intrinsic will give everybody a clearer target to aim for. Unit test the intrinsic optimization, and several similar formulations.
>>
>> ? John
>>


From staffan.larsen at oracle.com  Fri May  9 10:47:23 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 9 May 2014 12:47:23 +0200
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with
	assert(_cur_stack_depth == count_frames()) failed:
	cur_stack_depth out of sync
In-Reply-To: <536BB959.7060706@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>
	<536BB959.7060706@oracle.com>
Message-ID: <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>


On 8 maj 2014, at 19:05, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:

> > webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
> 
> src/share/vm/runtime/sharedRuntime.hpp
>    No comments.
> 
> src/share/vm/runtime/sharedRuntime.cpp
>    line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit(
>        I'm not sure that JRT_LEAF is right. I would think that
>        JvmtiExport::post_method_exit() would have to grab one or
>        more locks with all the state checks it has to make...
> 
>        For reference, InterpreterRuntime::post_method_exit()
>        is a wrapper around JvmtiExport::post_method_exit()
>        and it is IRT_ENTRY instead of IRT_LEAF.

Good catch!

> 
> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>    No comments.
> 
> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>    No comments.
> 
> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>    No comments.
> 
> I'm guessing that PPC has the same issue, but I'm presuming
> that someone else (Vladimir?) will handle that?

Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix.

Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/

Thanks,
/Staffan

> 
> Dan
> 
> 
> On 5/8/14 12:06 AM, Staffan Larsen wrote:
>> All,
>> 
>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
>> 
>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
>> 
>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
>> 
>> Kudos to Rickard for helping me write the code.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934
>> 
>> The fix has been verified by running the failing test in JPRT with -Xcomp.
>> 
>> Thanks,
>> /Staffan
> 


From daniel.daugherty at oracle.com  Fri May  9 14:01:20 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 09 May 2014 08:01:20 -0600
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms
	with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth
	out of sync
In-Reply-To: <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>
	<536BB959.7060706@oracle.com>
	<2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>
Message-ID: <536CDFB0.2000309@oracle.com>

 > Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/

Thumbs up!

src/share/vm/runtime/sharedRuntime.hpp
     No comments.

src/share/vm/runtime/sharedRuntime.cpp
     Thanks for fixing the entry type.

src/cpu/sparc/vm/sharedRuntime_sparc.cpp
     No comments.

src/cpu/x86/vm/sharedRuntime_x86_32.cpp
     No comments.

src/cpu/x86/vm/sharedRuntime_x86_64.cpp
     No comments.

Dan


On 5/9/14 4:47 AM, Staffan Larsen wrote:
> On 8 maj 2014, at 19:05, Daniel D. Daugherty<daniel.daugherty at oracle.com>  wrote:
>
>>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>> src/share/vm/runtime/sharedRuntime.hpp
>>     No comments.
>>
>> src/share/vm/runtime/sharedRuntime.cpp
>>     line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit(
>>         I'm not sure that JRT_LEAF is right. I would think that
>>         JvmtiExport::post_method_exit() would have to grab one or
>>         more locks with all the state checks it has to make...
>>
>>         For reference, InterpreterRuntime::post_method_exit()
>>         is a wrapper around JvmtiExport::post_method_exit()
>>         and it is IRT_ENTRY instead of IRT_LEAF.
> Good catch!
>
>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>     No comments.
>>
>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>     No comments.
>>
>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>     No comments.
>>
>> I'm guessing that PPC has the same issue, but I'm presuming
>> that someone else (Vladimir?) will handle that?
> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix.
>
> Updated review:http://cr.openjdk.java.net/~sla/8041934/webrev.01/
>
> Thanks,
> /Staffan
>
>> Dan
>>
>>
>> On 5/8/14 12:06 AM, Staffan Larsen wrote:
>>> All,
>>>
>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
>>>
>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
>>>
>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
>>>
>>> Kudos to Rickard for helping me write the code.
>>>
>>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>> bug:https://bugs.openjdk.java.net/browse/JDK-8041934
>>>
>>> The fix has been verified by running the failing test in JPRT with -Xcomp.
>>>
>>> Thanks,
>>> /Staffan


From christian.thalinger at oracle.com  Fri May  9 17:57:25 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 9 May 2014 07:57:25 -1000
Subject: [9] RFR(S): 8021770: BackEdgeThreshold option is no longer used
	and should be removed
In-Reply-To: <536C77AE.9040104@oracle.com>
References: <536C77AE.9040104@oracle.com>
Message-ID: <F9E2988C-72B7-450F-983F-CD11FADD3825@oracle.com>

Looks good.

On May 8, 2014, at 8:37 PM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi,
> 
> please review the following patch for 8021770. The corresponding CCC request is approved.
> 
> The BackEdgeThreshold option is removed because it is no longer used. 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8021770
> Webrev: http://cr.openjdk.java.net/~anoll/8021770/webrev.00/
> 
> Thanks,
> Tobias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140509/2f4a05ad/attachment.html>

From vladimir.kozlov at oracle.com  Fri May  9 18:16:00 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 09 May 2014 11:16:00 -0700
Subject: [9] RFR(S): 8021770: BackEdgeThreshold option is no longer used
	and should be removed
In-Reply-To: <536C77AE.9040104@oracle.com>
References: <536C77AE.9040104@oracle.com>
Message-ID: <536D1B60.3040107@oracle.com>

Add this flag to obsolete_jvm_flags table to get warning as Chris Plummer asked.

Thanks,
Vladimir

On 5/8/14 11:37 PM, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch for 8021770. The corresponding CCC request is approved.
>
> The BackEdgeThreshold option is removed because it is no longer used.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8021770
> Webrev: http://cr.openjdk.java.net/~anoll/8021770/webrev.00/
>
> Thanks,
> Tobias

From serguei.spitsyn at oracle.com  Fri May  9 18:18:04 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 09 May 2014 11:18:04 -0700
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms
	with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth
	out of sync
In-Reply-To: <2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>	<536BB959.7060706@oracle.com>
	<2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>
Message-ID: <536D1BDC.7000908@oracle.com>

Staffan,

This is important discovery, thanks!
The fix looks good to me.
One question below.

Thanks,
Serguei


On 5/9/14 3:47 AM, Staffan Larsen wrote:
> On 8 maj 2014, at 19:05, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>
>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>> src/share/vm/runtime/sharedRuntime.hpp
>>     No comments.
>>
>> src/share/vm/runtime/sharedRuntime.cpp
>>     line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit(
>>         I'm not sure that JRT_LEAF is right. I would think that
>>         JvmtiExport::post_method_exit() would have to grab one or
>>         more locks with all the state checks it has to make...
>>
>>         For reference, InterpreterRuntime::post_method_exit()
>>         is a wrapper around JvmtiExport::post_method_exit()
>>         and it is IRT_ENTRY instead of IRT_LEAF.
> Good catch!

Q: Is correct to use call_VM_leaf (vs call_VM ) in the  
sharedRuntime_<arch>.cpp ?

+    __ call_VM_leaf(
+         CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit),
+         thread, rax);



>
>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>     No comments.
>>
>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>     No comments.
>>
>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>     No comments.
>>
>> I'm guessing that PPC has the same issue, but I'm presuming
>> that someone else (Vladimir?) will handle that?
> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix.
>
> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/
>
> Thanks,
> /Staffan
>
>> Dan
>>
>>
>> On 5/8/14 12:06 AM, Staffan Larsen wrote:
>>> All,
>>>
>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
>>>
>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
>>>
>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
>>>
>>> Kudos to Rickard for helping me write the code.
>>>
>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934
>>>
>>> The fix has been verified by running the failing test in JPRT with -Xcomp.
>>>
>>> Thanks,
>>> /Staffan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140509/3a24ce6f/attachment.html>

From niclas.adlertz at oracle.com  Fri May  9 18:32:39 2014
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Fri, 09 May 2014 20:32:39 +0200
Subject: [8u20] RFR: 8029302: Performance regression in Math.pow intrinsic
Message-ID: <536D1F47.1090104@oracle.com>

Hi all,

Please review the backport of 8029302 together with 8042052, where 
8042052 fixed an issue introduced by 8029302.

The changesets apply cleanly. I intend push 8029302 and 8042052 as 
separate changesets.

8029302: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6314
          http://cr.openjdk.java.net/~adlertz/JDK-8029302/webrev01/

8042052: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/6385
          http://cr.openjdk.java.net/~anoll/8042052/webrev.01/

Kind Regards,
Niclas Adlertz

From tobias.hartmann at oracle.com  Mon May 12 07:33:00 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 12 May 2014 09:33:00 +0200
Subject: [9] RFR(S): 8021770: BackEdgeThreshold option is no longer used
	and should be removed
In-Reply-To: <536D1B60.3040107@oracle.com>
References: <536C77AE.9040104@oracle.com> <536D1B60.3040107@oracle.com>
Message-ID: <5370792C.4080007@oracle.com>

Christian, Vladimir, thanks for the reviews.

On 09.05.2014 20:16, Vladimir Kozlov wrote:
> Add this flag to obsolete_jvm_flags table to get warning as Chris 
> Plummer asked.

I added the BackEdgeThreshold flag to obsolete_jvm_flags.

New webrev: http://cr.openjdk.java.net/~anoll/8021770/webrev.01/

Thanks,
Tobias

>
> Thanks,
> Vladimir
>
> On 5/8/14 11:37 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> please review the following patch for 8021770. The corresponding CCC 
>> request is approved.
>>
>> The BackEdgeThreshold option is removed because it is no longer used.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8021770
>> Webrev: http://cr.openjdk.java.net/~anoll/8021770/webrev.00/
>>
>> Thanks,
>> Tobias


From vladimir.kozlov at oracle.com  Mon May 12 17:30:06 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 12 May 2014 10:30:06 -0700
Subject: [9] RFR(S): 8021770: BackEdgeThreshold option is no longer used
	and should be removed
In-Reply-To: <5370792C.4080007@oracle.com>
References: <536C77AE.9040104@oracle.com> <536D1B60.3040107@oracle.com>
	<5370792C.4080007@oracle.com>
Message-ID: <5371051E.1020703@oracle.com>

Good.

Thanks,
Vladimir

On 5/12/14 12:33 AM, Tobias Hartmann wrote:
> Christian, Vladimir, thanks for the reviews.
>
> On 09.05.2014 20:16, Vladimir Kozlov wrote:
>> Add this flag to obsolete_jvm_flags table to get warning as Chris Plummer asked.
>
> I added the BackEdgeThreshold flag to obsolete_jvm_flags.
>
> New webrev: http://cr.openjdk.java.net/~anoll/8021770/webrev.01/
>
> Thanks,
> Tobias
>
>>
>> Thanks,
>> Vladimir
>>
>> On 5/8/14 11:37 PM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> please review the following patch for 8021770. The corresponding CCC request is approved.
>>>
>>> The BackEdgeThreshold option is removed because it is no longer used.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8021770
>>> Webrev: http://cr.openjdk.java.net/~anoll/8021770/webrev.00/
>>>
>>> Thanks,
>>> Tobias
>

From vladimir.x.ivanov at oracle.com  Mon May 12 18:15:03 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 12 May 2014 22:15:03 +0400
Subject: RFR (XXS): 8023461: Thread holding lock at safepoint that vm can
	block on: MethodCompileQueue_lock
Message-ID: <53710FA7.5030909@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8023461/webrev.02/
https://bugs.openjdk.java.net/browse/JDK-8023461

CompileQueue::get() acquires MethodCompileQueue lock before extracting a 
task from the compilation queue. In Tiered mode it calls 
AdvancedThresholdPolicy::select_task, which can safepoint in multiple 
places. It fires an assert which checks there are no VM locks held VM 
thread can block on.

I checked the code and didn't find any scenarios where VM acquires MCQ 
lock and submits a compilation task from a safepoint, so I decided to 
relax the assert in Thread::check_for_valid_safepoint_state for now and 
exclude MethodCompileQueue in Tiered mode from the check.

I tried to rewrite ATP::select_task to avoid safepoints, but didn't 
succeed. I filed a RFE to further investigate that path (JDK-8042925 
[3]: Consider avoiding safepoints in ...::select_task). Eventually I 
want ATP::select_task to become safepoint-free and then strengthen the 
check back.

For the problems spotted during analysis, I filed 2 followup bugs:
   [1] JDK-8042924: Possible memory leak during MethodCounters 
initialization
   [2] JDK-8042926: AdvancedThresholdPolicy::update_rate should use 
handles for Method*

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8042924
[2] https://bugs.openjdk.java.net/browse/JDK-8042926
[3] https://bugs.openjdk.java.net/browse/JDK-8042925

From christian.thalinger at oracle.com  Mon May 12 19:27:55 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 12 May 2014 12:27:55 -0700
Subject: [9] RFR(S): 8021770: BackEdgeThreshold option is no longer used
	and should be removed
In-Reply-To: <5370792C.4080007@oracle.com>
References: <536C77AE.9040104@oracle.com> <536D1B60.3040107@oracle.com>
	<5370792C.4080007@oracle.com>
Message-ID: <05334F81-B56A-4561-B91B-F200F9AADBA6@oracle.com>

Looks good.

On May 12, 2014, at 12:33 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Christian, Vladimir, thanks for the reviews.
> 
> On 09.05.2014 20:16, Vladimir Kozlov wrote:
>> Add this flag to obsolete_jvm_flags table to get warning as Chris Plummer asked.
> 
> I added the BackEdgeThreshold flag to obsolete_jvm_flags.
> 
> New webrev: http://cr.openjdk.java.net/~anoll/8021770/webrev.01/
> 
> Thanks,
> Tobias
> 
>> 
>> Thanks,
>> Vladimir
>> 
>> On 5/8/14 11:37 PM, Tobias Hartmann wrote:
>>> Hi,
>>> 
>>> please review the following patch for 8021770. The corresponding CCC request is approved.
>>> 
>>> The BackEdgeThreshold option is removed because it is no longer used.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8021770
>>> Webrev: http://cr.openjdk.java.net/~anoll/8021770/webrev.00/
>>> 
>>> Thanks,
>>> Tobias
> 


From vladimir.kozlov at oracle.com  Mon May 12 23:59:29 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 12 May 2014 16:59:29 -0700
Subject: RFR (XXS): 8023461: Thread holding lock at safepoint that vm
	can block on: MethodCompileQueue_lock
In-Reply-To: <53710FA7.5030909@oracle.com>
References: <53710FA7.5030909@oracle.com>
Message-ID: <53716061.8000307@oracle.com>

Relaxing the check is not the fix. ATP::select_task() should be fixed - 
exclude safepoints in it.
The update_rate() could be not called if there are no MethodCounters 
(other places may need to be fixed for that). Actually I don't 
understand how we have compilation request for a method without 
MethodCounters. Counters should be created before that.
And removing stale tasks could be done in an other place, outside MCQ lock.

Thanks,
Vladimir K

On 5/12/14 11:15 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.02/
> https://bugs.openjdk.java.net/browse/JDK-8023461
>
> CompileQueue::get() acquires MethodCompileQueue lock before extracting a
> task from the compilation queue. In Tiered mode it calls
> AdvancedThresholdPolicy::select_task, which can safepoint in multiple
> places. It fires an assert which checks there are no VM locks held VM
> thread can block on.
>
> I checked the code and didn't find any scenarios where VM acquires MCQ
> lock and submits a compilation task from a safepoint, so I decided to
> relax the assert in Thread::check_for_valid_safepoint_state for now and
> exclude MethodCompileQueue in Tiered mode from the check.
>
> I tried to rewrite ATP::select_task to avoid safepoints, but didn't
> succeed. I filed a RFE to further investigate that path (JDK-8042925
> [3]: Consider avoiding safepoints in ...::select_task). Eventually I
> want ATP::select_task to become safepoint-free and then strengthen the
> check back.
>
> For the problems spotted during analysis, I filed 2 followup bugs:
>    [1] JDK-8042924: Possible memory leak during MethodCounters
> initialization
>    [2] JDK-8042926: AdvancedThresholdPolicy::update_rate should use
> handles for Method*
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8042924
> [2] https://bugs.openjdk.java.net/browse/JDK-8042926
> [3] https://bugs.openjdk.java.net/browse/JDK-8042925

From staffan.larsen at oracle.com  Tue May 13 09:20:41 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 13 May 2014 11:20:41 +0200
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with
	assert(_cur_stack_depth == count_frames()) failed:
	cur_stack_depth out of sync
In-Reply-To: <536D1BDC.7000908@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>	<536BB959.7060706@oracle.com>
	<2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>
	<536D1BDC.7000908@oracle.com>
Message-ID: <C6B702AE-DCB5-4E11-8879-D8540E3E969A@oracle.com>


On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com wrote:

> Staffan,
> 
> This is important discovery, thanks!
> The fix looks good to me.
> One question below.
> 
> Thanks,
> Serguei
> 
> 
> On 5/9/14 3:47 AM, Staffan Larsen wrote:
>> On 8 maj 2014, at 19:05, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>> 
>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>> src/share/vm/runtime/sharedRuntime.hpp
>>>    No comments.
>>> 
>>> src/share/vm/runtime/sharedRuntime.cpp
>>>    line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit(
>>>        I'm not sure that JRT_LEAF is right. I would think that
>>>        JvmtiExport::post_method_exit() would have to grab one or
>>>        more locks with all the state checks it has to make...
>>> 
>>>        For reference, InterpreterRuntime::post_method_exit()
>>>        is a wrapper around JvmtiExport::post_method_exit()
>>>        and it is IRT_ENTRY instead of IRT_LEAF.
>> Good catch!
> 
> Q: Is correct to use call_VM_leaf (vs call_VM ) in the  sharedRuntime_<arch>.cpp ?
> 
> +    __ call_VM_leaf(
> +         CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit),
> +         thread, rax);

That is another good catch! It should probably be call_VM as you note. The reason for all these leaf references is because we used the dtrace probe as a template - obviously without fully understanding what we did :-/

I have changed to code to use call_VM instead. This also required a change from jccb to jcc for the jump (which is now longer than an 8-bit offset). 

new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/

Thanks,
/Staffan


> 
>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>>    No comments.
>>> 
>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>>    No comments.
>>> 
>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>>    No comments.
>>> 
>>> I'm guessing that PPC has the same issue, but I'm presuming
>>> that someone else (Vladimir?) will handle that?
>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix.
>> 
>> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/
>> 
>> Thanks,
>> /Staffan
>> 
>>> Dan
>>> 
>>> 
>>> On 5/8/14 12:06 AM, Staffan Larsen wrote:
>>>> All,
>>>> 
>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
>>>> 
>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
>>>> 
>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
>>>> 
>>>> Kudos to Rickard for helping me write the code.
>>>> 
>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934
>>>> 
>>>> The fix has been verified by running the failing test in JPRT with -Xcomp.
>>>> 
>>>> Thanks,
>>>> /Staffan
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140513/8fce29c8/attachment.html>

From tobias.hartmann at oracle.com  Tue May 13 10:43:18 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 13 May 2014 12:43:18 +0200
Subject: [9] RFR(S): 8021770: BackEdgeThreshold option is no longer used
	and should be removed
In-Reply-To: <05334F81-B56A-4561-B91B-F200F9AADBA6@oracle.com>
References: <536C77AE.9040104@oracle.com> <536D1B60.3040107@oracle.com>
	<5370792C.4080007@oracle.com>
	<05334F81-B56A-4561-B91B-F200F9AADBA6@oracle.com>
Message-ID: <5371F746.5090500@oracle.com>

Christian, Vladimir, thanks for the reviews.

Best,
Tobias

On 12.05.2014 21:27, Christian Thalinger wrote:
> Looks good.
>
> On May 12, 2014, at 12:33 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>
>> Christian, Vladimir, thanks for the reviews.
>>
>> On 09.05.2014 20:16, Vladimir Kozlov wrote:
>>> Add this flag to obsolete_jvm_flags table to get warning as Chris Plummer asked.
>> I added the BackEdgeThreshold flag to obsolete_jvm_flags.
>>
>> New webrev: http://cr.openjdk.java.net/~anoll/8021770/webrev.01/
>>
>> Thanks,
>> Tobias
>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/8/14 11:37 PM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> please review the following patch for 8021770. The corresponding CCC request is approved.
>>>>
>>>> The BackEdgeThreshold option is removed because it is no longer used.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8021770
>>>> Webrev: http://cr.openjdk.java.net/~anoll/8021770/webrev.00/
>>>>
>>>> Thanks,
>>>> Tobias


From paul.sandoz at oracle.com  Tue May 13 10:48:34 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 13 May 2014 12:48:34 +0200
Subject: Unsafe for array access
In-Reply-To: <A24120D6-D4FA-49C2-8029-D678984260D7@oracle.com>
References: <12C1134A-D491-4A59-ACF4-F6E2C10DA112@oracle.com>
	<A24120D6-D4FA-49C2-8029-D678984260D7@oracle.com>
Message-ID: <6EEBA584-D92E-462C-B1DA-9A65F39FB7DF@oracle.com>


On May 6, 2014, at 8:38 PM, John Rose <john.r.rose at oracle.com> wrote:

> Paul, this is a reasonable request.  Please file a P3 bug against the hotspot compiler.
> 

Thanks.  Logged:

  https://bugs.openjdk.java.net/browse/JDK-8042997

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140513/1bce9456/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140513/1bce9456/signature.asc>

From daniel.daugherty at oracle.com  Tue May 13 16:53:43 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 13 May 2014 10:53:43 -0600
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms
	with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth
	out of sync
In-Reply-To: <C6B702AE-DCB5-4E11-8879-D8540E3E969A@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>	<536BB959.7060706@oracle.com>
	<2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>
	<536D1BDC.7000908@oracle.com>
	<C6B702AE-DCB5-4E11-8879-D8540E3E969A@oracle.com>
Message-ID: <53724E17.2080406@oracle.com>

 > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/

src/share/vm/runtime/sharedRuntime.hpp
     No comments.

src/share/vm/runtime/sharedRuntime.cpp
     No comments.

src/cpu/sparc/vm/sharedRuntime_sparc.cpp
     No comments.

src/cpu/x86/vm/sharedRuntime_x86_32.cpp
     No comments.

src/cpu/x86/vm/sharedRuntime_x86_64.cpp
     No comments.

On the switch from call_VM_leaf() -> call_VM(), I looked through all
the mentions of the string call_VM in the three src/cpu files. Your
change adds the first call_VM() use in all three files and the other
places that mention the string "call_VM" seem to have gone through
a great deal of trouble not to use call_VM() directly. I have no
specific thing I think is wrong, but I find this data worrisome...

Thumbs up!

Dan


On 5/13/14 3:20 AM, Staffan Larsen wrote:
>
> On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com 
> <mailto:serguei.spitsyn at oracle.com> wrote:
>
>> Staffan,
>>
>> This is important discovery, thanks!
>> The fix looks good to me.
>> One question below.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 5/9/14 3:47 AM, Staffan Larsen wrote:
>>> On 8 maj 2014, at 19:05, Daniel D. Daugherty<daniel.daugherty at oracle.com>  wrote:
>>>
>>>>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>> src/share/vm/runtime/sharedRuntime.hpp
>>>>     No comments.
>>>>
>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>>     line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit(
>>>>         I'm not sure that JRT_LEAF is right. I would think that
>>>>         JvmtiExport::post_method_exit() would have to grab one or
>>>>         more locks with all the state checks it has to make...
>>>>
>>>>         For reference, InterpreterRuntime::post_method_exit()
>>>>         is a wrapper around JvmtiExport::post_method_exit()
>>>>         and it is IRT_ENTRY instead of IRT_LEAF.
>>> Good catch!
>>
>> Q: Is correct to use call_VM_leaf (vs call_VM ) in the  
>> sharedRuntime_<arch>.cpp ?
>>
>> +    __ call_VM_leaf(
>> +         CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit),
>> +         thread, rax);
>
> That is another good catch! It should probably be call_VM as you note. 
> The reason for all these leaf references is because we used the dtrace 
> probe as a template - obviously without fully understanding what we 
> did :-/
>
> I have changed to code to use call_VM instead. This also required a 
> change from jccb to jcc for the jump (which is now longer than an 
> 8-bit offset).
>
> new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ 
> <http://cr.openjdk.java.net/%7Esla/8041934/webrev.02/>
>
> Thanks,
> /Staffan
>
>
>>
>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>>>     No comments.
>>>>
>>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>>>     No comments.
>>>>
>>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>>>     No comments.
>>>>
>>>> I'm guessing that PPC has the same issue, but I'm presuming
>>>> that someone else (Vladimir?) will handle that?
>>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix.
>>>
>>> Updated review:http://cr.openjdk.java.net/~sla/8041934/webrev.01/
>>>
>>> Thanks,
>>> /Staffan
>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/8/14 12:06 AM, Staffan Larsen wrote:
>>>>> All,
>>>>>
>>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
>>>>>
>>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
>>>>>
>>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
>>>>>
>>>>> Kudos to Rickard for helping me write the code.
>>>>>
>>>>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8041934
>>>>>
>>>>> The fix has been verified by running the failing test in JPRT with -Xcomp.
>>>>>
>>>>> Thanks,
>>>>> /Staffan
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140513/02dfdfa9/attachment-0001.html>

From staffan.larsen at oracle.com  Tue May 13 18:30:33 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 13 May 2014 20:30:33 +0200
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with
	assert(_cur_stack_depth == count_frames()) failed:
	cur_stack_depth out of sync
In-Reply-To: <53724E17.2080406@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>	<536BB959.7060706@oracle.com>
	<2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>
	<536D1BDC.7000908@oracle.com>
	<C6B702AE-DCB5-4E11-8879-D8540E3E969A@oracle.com>
	<53724E17.2080406@oracle.com>
Message-ID: <5B0A0E2F-FD3C-47D1-85C5-0B4470FC4F9D@oracle.com>


On 13 maj 2014, at 18:53, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:

> > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/
> 
> src/share/vm/runtime/sharedRuntime.hpp
>     No comments.
> 
> src/share/vm/runtime/sharedRuntime.cpp
>     No comments.
> 
> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>     No comments.
> 
> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>     No comments.
> 
> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>     No comments.
> 
> On the switch from call_VM_leaf() -> call_VM(), I looked through all
> the mentions of the string call_VM in the three src/cpu files. Your
> change adds the first call_VM() use in all three files and the other
> places that mention the string "call_VM" seem to have gone through
> a great deal of trouble not to use call_VM() directly. I have no
> specific thing I think is wrong, but I find this data worrisome?

Yes, it would be great if someone from the compiler team could review this, too.

Thanks,
/Staffan

> 
> Thumbs up!
> 
> Dan
> 
> 
> On 5/13/14 3:20 AM, Staffan Larsen wrote:
>> 
>> On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com wrote:
>> 
>>> Staffan,
>>> 
>>> This is important discovery, thanks!
>>> The fix looks good to me.
>>> One question below.
>>> 
>>> Thanks,
>>> Serguei
>>> 
>>> 
>>> On 5/9/14 3:47 AM, Staffan Larsen wrote:
>>>> On 8 maj 2014, at 19:05, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>>> 
>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>>> src/share/vm/runtime/sharedRuntime.hpp
>>>>>    No comments.
>>>>> 
>>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>>>    line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit(
>>>>>        I'm not sure that JRT_LEAF is right. I would think that
>>>>>        JvmtiExport::post_method_exit() would have to grab one or
>>>>>        more locks with all the state checks it has to make...
>>>>> 
>>>>>        For reference, InterpreterRuntime::post_method_exit()
>>>>>        is a wrapper around JvmtiExport::post_method_exit()
>>>>>        and it is IRT_ENTRY instead of IRT_LEAF.
>>>> Good catch!
>>> 
>>> Q: Is correct to use call_VM_leaf (vs call_VM ) in the  sharedRuntime_<arch>.cpp ?
>>> 
>>> +    __ call_VM_leaf(
>>> +         CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit),
>>> +         thread, rax);
>> 
>> That is another good catch! It should probably be call_VM as you note. The reason for all these leaf references is because we used the dtrace probe as a template - obviously without fully understanding what we did :-/
>> 
>> I have changed to code to use call_VM instead. This also required a change from jccb to jcc for the jump (which is now longer than an 8-bit offset). 
>> 
>> new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>>> 
>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>>>>    No comments.
>>>>> 
>>>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>>>>    No comments.
>>>>> 
>>>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>>>>    No comments.
>>>>> 
>>>>> I'm guessing that PPC has the same issue, but I'm presuming
>>>>> that someone else (Vladimir?) will handle that?
>>>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix.
>>>> 
>>>> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/
>>>> 
>>>> Thanks,
>>>> /Staffan
>>>> 
>>>>> Dan
>>>>> 
>>>>> 
>>>>> On 5/8/14 12:06 AM, Staffan Larsen wrote:
>>>>>> All,
>>>>>> 
>>>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
>>>>>> 
>>>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
>>>>>> 
>>>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
>>>>>> 
>>>>>> Kudos to Rickard for helping me write the code.
>>>>>> 
>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934
>>>>>> 
>>>>>> The fix has been verified by running the failing test in JPRT with -Xcomp.
>>>>>> 
>>>>>> Thanks,
>>>>>> /Staffan
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140513/a541ed12/attachment.html>

From filipp.zhinkin at oracle.com  Tue May 13 18:49:25 2014
From: filipp.zhinkin at oracle.com (Filipp Zhinkin)
Date: Tue, 13 May 2014 22:49:25 +0400
Subject: RFR (S): JDK-8038924: Test bit-instructions fails with unexpected
	exit value on sparc
Message-ID: <53726935.90807@oracle.com>

Hi all,

please review fix forJDK-8038924.

CLI tests on BMI-related options previously took all externally passed 
VM options,
add options that should be tested and launch new VM with such 
combination of options.

Unfortunately, some options like IgnoreUnrecognizedVMOptions, can affect
processing of tested flags and in such case tests fail.

I've updated these tests so now they do not use externally passed options.
Also, I've fix silly issue with String::format in 
BMICommandLineOptionTestBase.java.

Webrev: http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.00/
Testing: manual and automated.

Thanks,
Filipp.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140513/e78fcdc6/attachment.html>

From filipp.zhinkin at oracle.com  Tue May 13 18:58:35 2014
From: filipp.zhinkin at oracle.com (Filipp Zhinkin)
Date: Tue, 13 May 2014 22:58:35 +0400
Subject: [8u20] RFR (XS): JDK-8042949: +UnlockExperimentalVMOptions missed
	from TestUseRTMLockingOptionOnUnsupportedVM.java test
Message-ID: <53726B5B.6050504@oracle.com>

Hi,

I'd like to fix small issue with TestUseRTMLockingOptionOnUnsupportedVM 
test.

While backporting it from 9 to 8u20 I forgot to add
+UnlockExperimentalVMOptionand test fails.Now I'm going to add missed flag.

Fix applicable only for 8u20, because in JDK 9 UseRTMLocking is product 
flag,
while in 8u20 it is experimental.

Webrev: http://cr.openjdk.java.net/~iignatyev/fzhinkin/8042949/webrev.00/
Testing done: manual and automated.

Thanks,
Filipp.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140513/ea0d6d8b/attachment.html>

From vladimir.kozlov at oracle.com  Tue May 13 19:12:15 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 13 May 2014 12:12:15 -0700
Subject: [8u20] RFR (XS): JDK-8042949: +UnlockExperimentalVMOptions missed
	from TestUseRTMLockingOptionOnUnsupportedVM.java test
In-Reply-To: <53726B5B.6050504@oracle.com>
References: <53726B5B.6050504@oracle.com>
Message-ID: <53726E8F.8060700@oracle.com>

Looks good.

Thanks,
Vladimir

On 5/13/14 11:58 AM, Filipp Zhinkin wrote:
> Hi,
>
> I'd like to fix small issue with TestUseRTMLockingOptionOnUnsupportedVM
> test.
>
> While backporting it from 9 to 8u20 I forgot to add
> +UnlockExperimentalVMOptionand test fails.Now I'm going to add missed flag.
>
> Fix applicable only for 8u20, because in JDK 9 UseRTMLocking is product
> flag,
> while in 8u20 it is experimental.
>
> Webrev: http://cr.openjdk.java.net/~iignatyev/fzhinkin/8042949/webrev.00/
> Testing done: manual and automated.
>
> Thanks,
> Filipp.

From vladimir.kozlov at oracle.com  Tue May 13 19:21:56 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 13 May 2014 12:21:56 -0700
Subject: RFR (S): JDK-8038924: Test bit-instructions fails with unexpected
	exit value on sparc
In-Reply-To: <53726935.90807@oracle.com>
References: <53726935.90807@oracle.com>
Message-ID: <537270D4.9090400@oracle.com>

On 5/13/14 11:49 AM, Filipp Zhinkin wrote:
> Hi all,
>
> please review fix forJDK-8038924.

Filipp, please, provide the link to the bug report in you RFR.

>
> CLI tests on BMI-related options previously took all externally passed
> VM options,
> add options that should be tested and launch new VM with such
> combination of options.
>
> Unfortunately, some options like IgnoreUnrecognizedVMOptions, can affect
> processing of tested flags and in such case tests fail.
>
> I've updated these tests so now they do not use externally passed options.

I don't think it is right solution. Some external flags could be 
important (DeoptimizeALot for example).

You can add -XX:-IgnoreUnrecognizedVMOptions to tests which you expect 
to fail (on platforms which does not have the feature). It will nullify 
this flag passed from CL.

Regards,
Vladimir

> Also, I've fix silly issue with String::format in
> BMICommandLineOptionTestBase.java.
>
> Webrev: http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.00/
> Testing: manual and automated.
>
> Thanks,
> Filipp.

From serguei.spitsyn at oracle.com  Tue May 13 20:03:47 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 13 May 2014 13:03:47 -0700
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms
	with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth
	out of sync
In-Reply-To: <C6B702AE-DCB5-4E11-8879-D8540E3E969A@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>	<536BB959.7060706@oracle.com>
	<2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>
	<536D1BDC.7000908@oracle.com>
	<C6B702AE-DCB5-4E11-8879-D8540E3E969A@oracle.com>
Message-ID: <53727AA3.8070500@oracle.com>

On 5/13/14 2:20 AM, Staffan Larsen wrote:
>
> On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com 
> <mailto:serguei.spitsyn at oracle.com> wrote:
>
>> Staffan,
>>
>> This is important discovery, thanks!
>> The fix looks good to me.
>> One question below.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 5/9/14 3:47 AM, Staffan Larsen wrote:
>>> On 8 maj 2014, at 19:05, Daniel D. Daugherty<daniel.daugherty at oracle.com>  wrote:
>>>
>>>>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>> src/share/vm/runtime/sharedRuntime.hpp
>>>>     No comments.
>>>>
>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>>     line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit(
>>>>         I'm not sure that JRT_LEAF is right. I would think that
>>>>         JvmtiExport::post_method_exit() would have to grab one or
>>>>         more locks with all the state checks it has to make...
>>>>
>>>>         For reference, InterpreterRuntime::post_method_exit()
>>>>         is a wrapper around JvmtiExport::post_method_exit()
>>>>         and it is IRT_ENTRY instead of IRT_LEAF.
>>> Good catch!
>>
>> Q: Is correct to use call_VM_leaf (vs call_VM ) in the  
>> sharedRuntime_<arch>.cpp ?
>>
>> +    __ call_VM_leaf(
>> +         CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit),
>> +         thread, rax);
>
> That is another good catch! It should probably be call_VM as you note. 
> The reason for all these leaf references is because we used the dtrace 
> probe as a template - obviously without fully understanding what we 
> did :-/
>
> I have changed to code to use call_VM instead. This also required a 
> change from jccb to jcc for the jump (which is now longer than an 
> 8-bit offset).
>
> new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/ 
> <http://cr.openjdk.java.net/%7Esla/8041934/webrev.02/>
>
> Thanks,
> /Staffan
>
>
>>
>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>>>     No comments.
>>>>
>>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>>>     No comments.
>>>>
>>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>>>     No comments.
>>>>
>>>> I'm guessing that PPC has the same issue, but I'm presuming
>>>> that someone else (Vladimir?) will handle that?
>>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix.
>>>
>>> Updated review:http://cr.openjdk.java.net/~sla/8041934/webrev.01/

Looks good to me.

Thanks,
Serguei

>>>
>>> Thanks,
>>> /Staffan
>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/8/14 12:06 AM, Staffan Larsen wrote:
>>>>> All,
>>>>>
>>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
>>>>>
>>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
>>>>>
>>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
>>>>>
>>>>> Kudos to Rickard for helping me write the code.
>>>>>
>>>>> webrev:http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>>> bug:https://bugs.openjdk.java.net/browse/JDK-8041934
>>>>>
>>>>> The fix has been verified by running the failing test in JPRT with -Xcomp.
>>>>>
>>>>> Thanks,
>>>>> /Staffan
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140513/cc8ee68b/attachment.html>

From vladimir.x.ivanov at oracle.com  Tue May 13 21:34:02 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 14 May 2014 01:34:02 +0400
Subject: RFR (XXS): 8023461: Thread holding lock at safepoint that vm
	can block on: MethodCompileQueue_lock
In-Reply-To: <53716061.8000307@oracle.com>
References: <53710FA7.5030909@oracle.com> <53716061.8000307@oracle.com>
Message-ID: <53728FCA.8050902@oracle.com>

> Relaxing the check is not the fix. ATP::select_task() should be fixed -
> exclude safepoints in it.
OK. I planned to fix select_task separately (filed RFE to track that), 
since people complains about intermittent failures during testing due to 
this bug and I have some concerns with the fix I had. But I'll try to 
fix it as part of this change then.

> The update_rate() could be not called if there are no MethodCounters
> (other places may need to be fixed for that). Actually I don't
> understand how we have compilation request for a method without
> MethodCounters. Counters should be created before that.
It's not always the case. MDO can be created first (e.g. compilation can 
force MDO creation [1]) and there's no need in MethodCounters (see 
InterpreterGenerator::generate_counter_incr [2]).

> And removing stale tasks could be done in an other place, outside MCQ lock.
I looked again closely at the code and I think I found a sweet spot.

Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8023461/webrev.03/

Testing: JPRT, VM testbase, bigapps, jtreg

Best regards,
Vladimir Ivanov

[1]
Method::build_interpreter_method_data(methodHandle, Thread*)
ciMethod::ensure_method_data(methodHandle)
ciMethod::ensure_method_data()
GraphBuilder::try_inline_full(ciMethod*, bool, Bytecodes::Code, 
Instruction*)

[2] 
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/src/cpu/x86/vm/templateInterpreter_x86_32.cpp#l340

> Thanks,
> Vladimir K
>
> On 5/12/14 11:15 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.02/
>> https://bugs.openjdk.java.net/browse/JDK-8023461
>>
>> CompileQueue::get() acquires MethodCompileQueue lock before extracting a
>> task from the compilation queue. In Tiered mode it calls
>> AdvancedThresholdPolicy::select_task, which can safepoint in multiple
>> places. It fires an assert which checks there are no VM locks held VM
>> thread can block on.
>>
>> I checked the code and didn't find any scenarios where VM acquires MCQ
>> lock and submits a compilation task from a safepoint, so I decided to
>> relax the assert in Thread::check_for_valid_safepoint_state for now and
>> exclude MethodCompileQueue in Tiered mode from the check.
>>
>> I tried to rewrite ATP::select_task to avoid safepoints, but didn't
>> succeed. I filed a RFE to further investigate that path (JDK-8042925
>> [3]: Consider avoiding safepoints in ...::select_task). Eventually I
>> want ATP::select_task to become safepoint-free and then strengthen the
>> check back.
>>
>> For the problems spotted during analysis, I filed 2 followup bugs:
>>    [1] JDK-8042924: Possible memory leak during MethodCounters
>> initialization
>>    [2] JDK-8042926: AdvancedThresholdPolicy::update_rate should use
>> handles for Method*
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8042924
>> [2] https://bugs.openjdk.java.net/browse/JDK-8042926
>> [3] https://bugs.openjdk.java.net/browse/JDK-8042925

From igor.veresov at oracle.com  Tue May 13 22:11:15 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 13 May 2014 15:11:15 -0700
Subject: RFR (XXS): 8023461: Thread holding lock at safepoint that vm can
	block on: MethodCompileQueue_lock
In-Reply-To: <53728FCA.8050902@oracle.com>
References: <53710FA7.5030909@oracle.com> <53716061.8000307@oracle.com>
	<53728FCA.8050902@oracle.com>
Message-ID: <E8E6534F-03F2-45B9-A701-5298C7F2A72A@oracle.com>

I think that?s reasonable. Thanks for pointing out the fact the we can have an MDO and no MC with, say, Xcomp and tiered. With your check in update_rate() we?ll no longer force their allocation. I?ll have add their allocation explicitly to the code aging code for that case.

Indent in remove_and_mark_stale() is off.

igor

On May 13, 2014, at 2:34 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

>> Relaxing the check is not the fix. ATP::select_task() should be fixed -
>> exclude safepoints in it.
> OK. I planned to fix select_task separately (filed RFE to track that), since people complains about intermittent failures during testing due to this bug and I have some concerns with the fix I had. But I'll try to fix it as part of this change then.
> 
>> The update_rate() could be not called if there are no MethodCounters
>> (other places may need to be fixed for that). Actually I don't
>> understand how we have compilation request for a method without
>> MethodCounters. Counters should be created before that.
> It's not always the case. MDO can be created first (e.g. compilation can force MDO creation [1]) and there's no need in MethodCounters (see InterpreterGenerator::generate_counter_incr [2]).
> 
>> And removing stale tasks could be done in an other place, outside MCQ lock.
> I looked again closely at the code and I think I found a sweet spot.
> 
> Updated webrev:
> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.03/
> 
> Testing: JPRT, VM testbase, bigapps, jtreg
> 
> Best regards,
> Vladimir Ivanov
> 
> [1]
> Method::build_interpreter_method_data(methodHandle, Thread*)
> ciMethod::ensure_method_data(methodHandle)
> ciMethod::ensure_method_data()
> GraphBuilder::try_inline_full(ciMethod*, bool, Bytecodes::Code, Instruction*)
> 
> [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/src/cpu/x86/vm/templateInterpreter_x86_32.cpp#l340
> 
>> Thanks,
>> Vladimir K
>> 
>> On 5/12/14 11:15 AM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.02/
>>> https://bugs.openjdk.java.net/browse/JDK-8023461
>>> 
>>> CompileQueue::get() acquires MethodCompileQueue lock before extracting a
>>> task from the compilation queue. In Tiered mode it calls
>>> AdvancedThresholdPolicy::select_task, which can safepoint in multiple
>>> places. It fires an assert which checks there are no VM locks held VM
>>> thread can block on.
>>> 
>>> I checked the code and didn't find any scenarios where VM acquires MCQ
>>> lock and submits a compilation task from a safepoint, so I decided to
>>> relax the assert in Thread::check_for_valid_safepoint_state for now and
>>> exclude MethodCompileQueue in Tiered mode from the check.
>>> 
>>> I tried to rewrite ATP::select_task to avoid safepoints, but didn't
>>> succeed. I filed a RFE to further investigate that path (JDK-8042925
>>> [3]: Consider avoiding safepoints in ...::select_task). Eventually I
>>> want ATP::select_task to become safepoint-free and then strengthen the
>>> check back.
>>> 
>>> For the problems spotted during analysis, I filed 2 followup bugs:
>>>   [1] JDK-8042924: Possible memory leak during MethodCounters
>>> initialization
>>>   [2] JDK-8042926: AdvancedThresholdPolicy::update_rate should use
>>> handles for Method*
>>> 
>>> Best regards,
>>> Vladimir Ivanov
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8042924
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8042926
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8042925


From christian.thalinger at oracle.com  Tue May 13 22:21:56 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 13 May 2014 15:21:56 -0700
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with
	assert(_cur_stack_depth == count_frames()) failed:
	cur_stack_depth out of sync
In-Reply-To: <5B0A0E2F-FD3C-47D1-85C5-0B4470FC4F9D@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>	<536BB959.7060706@oracle.com>
	<2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>
	<536D1BDC.7000908@oracle.com>
	<C6B702AE-DCB5-4E11-8879-D8540E3E969A@oracle.com>
	<53724E17.2080406@oracle.com>
	<5B0A0E2F-FD3C-47D1-85C5-0B4470FC4F9D@oracle.com>
Message-ID: <A6074FC1-35DD-4672-AB1C-020C2961CD55@oracle.com>

Since:

  int               _interp_only_mode;

is an int field I would prefer to actually read the value as an int instead of just a byte on x86:
+    __ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0);
Otherwise this looks good.

On May 13, 2014, at 11:30 AM, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> 
> On 13 maj 2014, at 18:53, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
> 
>> > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/
>> 
>> src/share/vm/runtime/sharedRuntime.hpp
>>     No comments.
>> 
>> src/share/vm/runtime/sharedRuntime.cpp
>>     No comments.
>> 
>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>     No comments.
>> 
>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>     No comments.
>> 
>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>     No comments.
>> 
>> On the switch from call_VM_leaf() -> call_VM(), I looked through all
>> the mentions of the string call_VM in the three src/cpu files. Your
>> change adds the first call_VM() use in all three files and the other
>> places that mention the string "call_VM" seem to have gone through
>> a great deal of trouble not to use call_VM() directly. I have no
>> specific thing I think is wrong, but I find this data worrisome?
> 
> Yes, it would be great if someone from the compiler team could review this, too.
> 
> Thanks,
> /Staffan
> 
>> 
>> Thumbs up!
>> 
>> Dan
>> 
>> 
>> On 5/13/14 3:20 AM, Staffan Larsen wrote:
>>> 
>>> On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com wrote:
>>> 
>>>> Staffan,
>>>> 
>>>> This is important discovery, thanks!
>>>> The fix looks good to me.
>>>> One question below.
>>>> 
>>>> Thanks,
>>>> Serguei
>>>> 
>>>> 
>>>> On 5/9/14 3:47 AM, Staffan Larsen wrote:
>>>>> On 8 maj 2014, at 19:05, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>>>> 
>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>>>> src/share/vm/runtime/sharedRuntime.hpp
>>>>>>    No comments.
>>>>>> 
>>>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>>>>    line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit(
>>>>>>        I'm not sure that JRT_LEAF is right. I would think that
>>>>>>        JvmtiExport::post_method_exit() would have to grab one or
>>>>>>        more locks with all the state checks it has to make...
>>>>>> 
>>>>>>        For reference, InterpreterRuntime::post_method_exit()
>>>>>>        is a wrapper around JvmtiExport::post_method_exit()
>>>>>>        and it is IRT_ENTRY instead of IRT_LEAF.
>>>>> Good catch!
>>>> 
>>>> Q: Is correct to use call_VM_leaf (vs call_VM ) in the  sharedRuntime_<arch>.cpp ?
>>>> 
>>>> +    __ call_VM_leaf(
>>>> +         CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit),
>>>> +         thread, rax);
>>> 
>>> That is another good catch! It should probably be call_VM as you note. The reason for all these leaf references is because we used the dtrace probe as a template - obviously without fully understanding what we did :-/
>>> 
>>> I have changed to code to use call_VM instead. This also required a change from jccb to jcc for the jump (which is now longer than an 8-bit offset). 
>>> 
>>> new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>> 
>>>> 
>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>>>>>    No comments.
>>>>>> 
>>>>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>>>>>    No comments.
>>>>>> 
>>>>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>>>>>    No comments.
>>>>>> 
>>>>>> I'm guessing that PPC has the same issue, but I'm presuming
>>>>>> that someone else (Vladimir?) will handle that?
>>>>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix.
>>>>> 
>>>>> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/
>>>>> 
>>>>> Thanks,
>>>>> /Staffan
>>>>> 
>>>>>> Dan
>>>>>> 
>>>>>> 
>>>>>> On 5/8/14 12:06 AM, Staffan Larsen wrote:
>>>>>>> All,
>>>>>>> 
>>>>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
>>>>>>> 
>>>>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
>>>>>>> 
>>>>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
>>>>>>> 
>>>>>>> Kudos to Rickard for helping me write the code.
>>>>>>> 
>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934
>>>>>>> 
>>>>>>> The fix has been verified by running the failing test in JPRT with -Xcomp.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> /Staffan
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140513/491e9a8e/attachment.html>

From vladimir.x.ivanov at oracle.com  Tue May 13 22:33:38 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 14 May 2014 02:33:38 +0400
Subject: RFR (XXS): 8023461: Thread holding lock at safepoint that vm
	can block on: MethodCompileQueue_lock
In-Reply-To: <E8E6534F-03F2-45B9-A701-5298C7F2A72A@oracle.com>
References: <53710FA7.5030909@oracle.com> <53716061.8000307@oracle.com>
	<53728FCA.8050902@oracle.com>
	<E8E6534F-03F2-45B9-A701-5298C7F2A72A@oracle.com>
Message-ID: <53729DC2.108@oracle.com>

Igor, thanks!

> I think that?s reasonable. Thanks for pointing out the fact the we can have an MDO and no MC with, say, Xcomp and tiered. With your check in update_rate() we?ll no longer force their allocation. I?ll have add their allocation explicitly to the code aging code for that case.
Not necessarily -Xcomp + Tiered. There are rare cases in normal mode as 
well (-Xmixed).

> Indent in remove_and_mark_stale() is off.
Fixed.

Best regards,
Vladimir Ivanov
>
> igor
>
> On May 13, 2014, at 2:34 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>>> Relaxing the check is not the fix. ATP::select_task() should be fixed -
>>> exclude safepoints in it.
>> OK. I planned to fix select_task separately (filed RFE to track that), since people complains about intermittent failures during testing due to this bug and I have some concerns with the fix I had. But I'll try to fix it as part of this change then.
>>
>>> The update_rate() could be not called if there are no MethodCounters
>>> (other places may need to be fixed for that). Actually I don't
>>> understand how we have compilation request for a method without
>>> MethodCounters. Counters should be created before that.
>> It's not always the case. MDO can be created first (e.g. compilation can force MDO creation [1]) and there's no need in MethodCounters (see InterpreterGenerator::generate_counter_incr [2]).
>>
>>> And removing stale tasks could be done in an other place, outside MCQ lock.
>> I looked again closely at the code and I think I found a sweet spot.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.03/
>>
>> Testing: JPRT, VM testbase, bigapps, jtreg
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1]
>> Method::build_interpreter_method_data(methodHandle, Thread*)
>> ciMethod::ensure_method_data(methodHandle)
>> ciMethod::ensure_method_data()
>> GraphBuilder::try_inline_full(ciMethod*, bool, Bytecodes::Code, Instruction*)
>>
>> [2] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/src/cpu/x86/vm/templateInterpreter_x86_32.cpp#l340
>>
>>> Thanks,
>>> Vladimir K
>>>
>>> On 5/12/14 11:15 AM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.02/
>>>> https://bugs.openjdk.java.net/browse/JDK-8023461
>>>>
>>>> CompileQueue::get() acquires MethodCompileQueue lock before extracting a
>>>> task from the compilation queue. In Tiered mode it calls
>>>> AdvancedThresholdPolicy::select_task, which can safepoint in multiple
>>>> places. It fires an assert which checks there are no VM locks held VM
>>>> thread can block on.
>>>>
>>>> I checked the code and didn't find any scenarios where VM acquires MCQ
>>>> lock and submits a compilation task from a safepoint, so I decided to
>>>> relax the assert in Thread::check_for_valid_safepoint_state for now and
>>>> exclude MethodCompileQueue in Tiered mode from the check.
>>>>
>>>> I tried to rewrite ATP::select_task to avoid safepoints, but didn't
>>>> succeed. I filed a RFE to further investigate that path (JDK-8042925
>>>> [3]: Consider avoiding safepoints in ...::select_task). Eventually I
>>>> want ATP::select_task to become safepoint-free and then strengthen the
>>>> check back.
>>>>
>>>> For the problems spotted during analysis, I filed 2 followup bugs:
>>>>    [1] JDK-8042924: Possible memory leak during MethodCounters
>>>> initialization
>>>>    [2] JDK-8042926: AdvancedThresholdPolicy::update_rate should use
>>>> handles for Method*
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8042924
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8042926
>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8042925
>

From vladimir.kozlov at oracle.com  Tue May 13 22:58:31 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 13 May 2014 15:58:31 -0700
Subject: RFR (XXS): 8023461: Thread holding lock at safepoint that vm
	can block on: MethodCompileQueue_lock
In-Reply-To: <53728FCA.8050902@oracle.com>
References: <53710FA7.5030909@oracle.com> <53716061.8000307@oracle.com>
	<53728FCA.8050902@oracle.com>
Message-ID: <5372A397.8060407@oracle.com>

On 5/13/14 2:34 PM, Vladimir Ivanov wrote:
>> Relaxing the check is not the fix. ATP::select_task() should be fixed -
>> exclude safepoints in it.
> OK. I planned to fix select_task separately (filed RFE to track that),
> since people complains about intermittent failures during testing due to
> this bug and I have some concerns with the fix I had. But I'll try to
> fix it as part of this change then.
>
>> The update_rate() could be not called if there are no MethodCounters
>> (other places may need to be fixed for that). Actually I don't
>> understand how we have compilation request for a method without
>> MethodCounters. Counters should be created before that.
> It's not always the case. MDO can be created first (e.g. compilation can
> force MDO creation [1]) and there's no need in MethodCounters (see
> InterpreterGenerator::generate_counter_incr [2]).

I think this is contradiction in tiered implementation. We don't 
allocate MethodCounters for TieredCompilation as you pointed but tiered 
code uses them.

>
>> And removing stale tasks could be done in an other place, outside MCQ
>> lock.
> I looked again closely at the code and I think I found a sweet spot.
>
> Updated webrev:
> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.03/

Very good. Add small comment explaining your trick to avoid conflicts 
with other compiler threads after lock is released:

+     CompileTask* head = _first_stale;
+     _first_stale = NULL;

Thanks,
Vladimir

>
> Testing: JPRT, VM testbase, bigapps, jtreg
>
> Best regards,
> Vladimir Ivanov
>
> [1]
> Method::build_interpreter_method_data(methodHandle, Thread*)
> ciMethod::ensure_method_data(methodHandle)
> ciMethod::ensure_method_data()
> GraphBuilder::try_inline_full(ciMethod*, bool, Bytecodes::Code,
> Instruction*)
>
> [2]
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/src/cpu/x86/vm/templateInterpreter_x86_32.cpp#l340
>
>
>> Thanks,
>> Vladimir K
>>
>> On 5/12/14 11:15 AM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.02/
>>> https://bugs.openjdk.java.net/browse/JDK-8023461
>>>
>>> CompileQueue::get() acquires MethodCompileQueue lock before extracting a
>>> task from the compilation queue. In Tiered mode it calls
>>> AdvancedThresholdPolicy::select_task, which can safepoint in multiple
>>> places. It fires an assert which checks there are no VM locks held VM
>>> thread can block on.
>>>
>>> I checked the code and didn't find any scenarios where VM acquires MCQ
>>> lock and submits a compilation task from a safepoint, so I decided to
>>> relax the assert in Thread::check_for_valid_safepoint_state for now and
>>> exclude MethodCompileQueue in Tiered mode from the check.
>>>
>>> I tried to rewrite ATP::select_task to avoid safepoints, but didn't
>>> succeed. I filed a RFE to further investigate that path (JDK-8042925
>>> [3]: Consider avoiding safepoints in ...::select_task). Eventually I
>>> want ATP::select_task to become safepoint-free and then strengthen the
>>> check back.
>>>
>>> For the problems spotted during analysis, I filed 2 followup bugs:
>>>    [1] JDK-8042924: Possible memory leak during MethodCounters
>>> initialization
>>>    [2] JDK-8042926: AdvancedThresholdPolicy::update_rate should use
>>> handles for Method*
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8042924
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8042926
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8042925

From vladimir.x.ivanov at oracle.com  Tue May 13 23:23:17 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 14 May 2014 03:23:17 +0400
Subject: RFR (XXS): 8023461: Thread holding lock at safepoint that vm
	can block on: MethodCompileQueue_lock
In-Reply-To: <5372A397.8060407@oracle.com>
References: <53710FA7.5030909@oracle.com>
	<53716061.8000307@oracle.com>	<53728FCA.8050902@oracle.com>
	<5372A397.8060407@oracle.com>
Message-ID: <5372A965.5080201@oracle.com>

Vladimir, thanks!

On 5/14/14 2:58 AM, Vladimir Kozlov wrote:
> On 5/13/14 2:34 PM, Vladimir Ivanov wrote:
>>> Relaxing the check is not the fix. ATP::select_task() should be fixed -
>>> exclude safepoints in it.
>> OK. I planned to fix select_task separately (filed RFE to track that),
>> since people complains about intermittent failures during testing due to
>> this bug and I have some concerns with the fix I had. But I'll try to
>> fix it as part of this change then.
>>
>>> The update_rate() could be not called if there are no MethodCounters
>>> (other places may need to be fixed for that). Actually I don't
>>> understand how we have compilation request for a method without
>>> MethodCounters. Counters should be created before that.
>> It's not always the case. MDO can be created first (e.g. compilation can
>> force MDO creation [1]) and there's no need in MethodCounters (see
>> InterpreterGenerator::generate_counter_incr [2]).
>
> I think this is contradiction in tiered implementation. We don't
> allocate MethodCounters for TieredCompilation as you pointed but tiered
> code uses them.
I agree. Filed JDK-8043061 to track that.

>>
>>> And removing stale tasks could be done in an other place, outside MCQ
>>> lock.
>> I looked again closely at the code and I think I found a sweet spot.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.03/
>
> Very good. Add small comment explaining your trick to avoid conflicts
> with other compiler threads after lock is released:
>
> +     CompileTask* head = _first_stale;
> +     _first_stale = NULL;
Updated webrev in place with a comment:
http://cr.openjdk.java.net/~vlivanov/8023461/webrev.03/

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8043061

From vladimir.kozlov at oracle.com  Tue May 13 23:24:54 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 13 May 2014 16:24:54 -0700
Subject: RFR (XXS): 8023461: Thread holding lock at safepoint that vm
	can block on: MethodCompileQueue_lock
In-Reply-To: <5372A965.5080201@oracle.com>
References: <53710FA7.5030909@oracle.com>
	<53716061.8000307@oracle.com>	<53728FCA.8050902@oracle.com>
	<5372A397.8060407@oracle.com> <5372A965.5080201@oracle.com>
Message-ID: <5372A9C6.1090807@oracle.com>

Nice.

Thanks,
Vladimir

On 5/13/14 4:23 PM, Vladimir Ivanov wrote:
> Vladimir, thanks!
>
> On 5/14/14 2:58 AM, Vladimir Kozlov wrote:
>> On 5/13/14 2:34 PM, Vladimir Ivanov wrote:
>>>> Relaxing the check is not the fix. ATP::select_task() should be fixed -
>>>> exclude safepoints in it.
>>> OK. I planned to fix select_task separately (filed RFE to track that),
>>> since people complains about intermittent failures during testing due to
>>> this bug and I have some concerns with the fix I had. But I'll try to
>>> fix it as part of this change then.
>>>
>>>> The update_rate() could be not called if there are no MethodCounters
>>>> (other places may need to be fixed for that). Actually I don't
>>>> understand how we have compilation request for a method without
>>>> MethodCounters. Counters should be created before that.
>>> It's not always the case. MDO can be created first (e.g. compilation can
>>> force MDO creation [1]) and there's no need in MethodCounters (see
>>> InterpreterGenerator::generate_counter_incr [2]).
>>
>> I think this is contradiction in tiered implementation. We don't
>> allocate MethodCounters for TieredCompilation as you pointed but tiered
>> code uses them.
> I agree. Filed JDK-8043061 to track that.
>
>>>
>>>> And removing stale tasks could be done in an other place, outside MCQ
>>>> lock.
>>> I looked again closely at the code and I think I found a sweet spot.
>>>
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.03/
>>
>> Very good. Add small comment explaining your trick to avoid conflicts
>> with other compiler threads after lock is released:
>>
>> +     CompileTask* head = _first_stale;
>> +     _first_stale = NULL;
> Updated webrev in place with a comment:
> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.03/
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8043061

From vladimir.x.ivanov at oracle.com  Tue May 13 23:31:06 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 14 May 2014 03:31:06 +0400
Subject: RFR (XXS): 8023461: Thread holding lock at safepoint that vm
	can block on: MethodCompileQueue_lock
In-Reply-To: <5372A9C6.1090807@oracle.com>
References: <53710FA7.5030909@oracle.com>
	<53716061.8000307@oracle.com>	<53728FCA.8050902@oracle.com>
	<5372A397.8060407@oracle.com> <5372A965.5080201@oracle.com>
	<5372A9C6.1090807@oracle.com>
Message-ID: <5372AB3A.6040909@oracle.com>

Vladimir, thank you.

Best regards,
Vladimir Ivanov

On 5/14/14 3:24 AM, Vladimir Kozlov wrote:
> Nice.
>
> Thanks,
> Vladimir
>
> On 5/13/14 4:23 PM, Vladimir Ivanov wrote:
>> Vladimir, thanks!
>>
>> On 5/14/14 2:58 AM, Vladimir Kozlov wrote:
>>> On 5/13/14 2:34 PM, Vladimir Ivanov wrote:
>>>>> Relaxing the check is not the fix. ATP::select_task() should be
>>>>> fixed -
>>>>> exclude safepoints in it.
>>>> OK. I planned to fix select_task separately (filed RFE to track that),
>>>> since people complains about intermittent failures during testing
>>>> due to
>>>> this bug and I have some concerns with the fix I had. But I'll try to
>>>> fix it as part of this change then.
>>>>
>>>>> The update_rate() could be not called if there are no MethodCounters
>>>>> (other places may need to be fixed for that). Actually I don't
>>>>> understand how we have compilation request for a method without
>>>>> MethodCounters. Counters should be created before that.
>>>> It's not always the case. MDO can be created first (e.g. compilation
>>>> can
>>>> force MDO creation [1]) and there's no need in MethodCounters (see
>>>> InterpreterGenerator::generate_counter_incr [2]).
>>>
>>> I think this is contradiction in tiered implementation. We don't
>>> allocate MethodCounters for TieredCompilation as you pointed but tiered
>>> code uses them.
>> I agree. Filed JDK-8043061 to track that.
>>
>>>>
>>>>> And removing stale tasks could be done in an other place, outside MCQ
>>>>> lock.
>>>> I looked again closely at the code and I think I found a sweet spot.
>>>>
>>>> Updated webrev:
>>>> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.03/
>>>
>>> Very good. Add small comment explaining your trick to avoid conflicts
>>> with other compiler threads after lock is released:
>>>
>>> +     CompileTask* head = _first_stale;
>>> +     _first_stale = NULL;
>> Updated webrev in place with a comment:
>> http://cr.openjdk.java.net/~vlivanov/8023461/webrev.03/
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8043061

From igor.veresov at oracle.com  Wed May 14 00:45:41 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 13 May 2014 17:45:41 -0700
Subject: RFR(XS): 8043063: Code aging should allocate MethodCounters when
	flushing a method 
Message-ID: <5D2F008F-0CA5-48AB-A93E-3F1377CC8871@oracle.com>

In some edge cases we may not have MethodCounters allocated for a method that was compiled, like with -Xcomp.
So with code aging we need to allocate MCs when we are flushing the method to set up the aging counter.

Webrev: http://cr.openjdk.java.net/~iveresov/8043063/webrev.00/

Thanks!
igor

From vladimir.kozlov at oracle.com  Wed May 14 01:00:21 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 13 May 2014 18:00:21 -0700
Subject: RFR(XS): 8043063: Code aging should allocate MethodCounters when
	flushing a method
In-Reply-To: <5D2F008F-0CA5-48AB-A93E-3F1377CC8871@oracle.com>
References: <5D2F008F-0CA5-48AB-A93E-3F1377CC8871@oracle.com>
Message-ID: <5372C025.3070504@oracle.com>

I think this should be fixed in general (8043061). We should allocate 
MethodCounters at least when we create a compilation task.

Thanks,
Vladimir

On 5/13/14 5:45 PM, Igor Veresov wrote:
> In some edge cases we may not have MethodCounters allocated for a method that was compiled, like with -Xcomp.
> So with code aging we need to allocate MCs when we are flushing the method to set up the aging counter.
>
> Webrev: http://cr.openjdk.java.net/~iveresov/8043063/webrev.00/
>
> Thanks!
> igor
>

From igor.veresov at oracle.com  Wed May 14 01:11:48 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 13 May 2014 18:11:48 -0700
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't enter
	safepoint
Message-ID: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>

nmethod::verify_interrupt_point() is called from as part of nmethod verification from ciEnv::register_method() that asserts no safepoint can occur. However verify_interrupt_point() locks a mutex that may potentially safepoint. A sample call stack of when it happens is in the following JBS issue.

JBS: https://bugs.openjdk.java.net/browse/JDK-8043070
Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/

igor

From igor.veresov at oracle.com  Wed May 14 01:14:39 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 13 May 2014 18:14:39 -0700
Subject: RFR(XS): 8043063: Code aging should allocate MethodCounters when
	flushing a method
In-Reply-To: <5372C025.3070504@oracle.com>
References: <5D2F008F-0CA5-48AB-A93E-3F1377CC8871@oracle.com>
	<5372C025.3070504@oracle.com>
Message-ID: <A63840E5-9718-4BF0-B35B-E77301DC5760@oracle.com>

I don?t think it hurts to make sure they exist at this point in the sweeper. In addition to that, only AdvancedTieredPolicy needs them to be present if a method in the queue. Other policies could work fine without MCs, and for example with Xcomp. It would be needless to allocate MCs in that case.

igor

On May 13, 2014, at 6:00 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> I think this should be fixed in general (8043061). We should allocate MethodCounters at least when we create a compilation task.
> 
> Thanks,
> Vladimir
> 
> On 5/13/14 5:45 PM, Igor Veresov wrote:
>> In some edge cases we may not have MethodCounters allocated for a method that was compiled, like with -Xcomp.
>> So with code aging we need to allocate MCs when we are flushing the method to set up the aging counter.
>> 
>> Webrev: http://cr.openjdk.java.net/~iveresov/8043063/webrev.00/
>> 
>> Thanks!
>> igor
>> 


From vladimir.kozlov at oracle.com  Wed May 14 01:56:37 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 13 May 2014 18:56:37 -0700
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't
	enter safepoint
In-Reply-To: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
References: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
Message-ID: <5372CD55.60904@oracle.com>

Good.

Vladimir

On 5/13/14 6:11 PM, Igor Veresov wrote:
> nmethod::verify_interrupt_point() is called from as part of nmethod verification from ciEnv::register_method() that asserts no safepoint can occur. However verify_interrupt_point() locks a mutex that may potentially safepoint. A sample call stack of when it happens is in the following JBS issue.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070
> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/
>
> igor
>

From vladimir.kozlov at oracle.com  Wed May 14 02:01:27 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 13 May 2014 19:01:27 -0700
Subject: RFR(XS): 8043063: Code aging should allocate MethodCounters when
	flushing a method
In-Reply-To: <A63840E5-9718-4BF0-B35B-E77301DC5760@oracle.com>
References: <5D2F008F-0CA5-48AB-A93E-3F1377CC8871@oracle.com>	<5372C025.3070504@oracle.com>
	<A63840E5-9718-4BF0-B35B-E77301DC5760@oracle.com>
Message-ID: <5372CE77.6090900@oracle.com>

On 5/13/14 6:14 PM, Igor Veresov wrote:
> I don?t think it hurts to make sure they exist at this point in the sweeper. In addition to that, only AdvancedTieredPolicy needs them to be present if a method in the queue. Other policies could work fine without MCs, and for example with Xcomp. It would be needless to allocate MCs in that case.

Okay. Changes are good.

thanks,
Vladimir

>
> igor
>
> On May 13, 2014, at 6:00 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> I think this should be fixed in general (8043061). We should allocate MethodCounters at least when we create a compilation task.
>>
>> Thanks,
>> Vladimir
>>
>> On 5/13/14 5:45 PM, Igor Veresov wrote:
>>> In some edge cases we may not have MethodCounters allocated for a method that was compiled, like with -Xcomp.
>>> So with code aging we need to allocate MCs when we are flushing the method to set up the aging counter.
>>>
>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043063/webrev.00/
>>>
>>> Thanks!
>>> igor
>>>
>

From igor.veresov at oracle.com  Wed May 14 03:53:02 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 13 May 2014 20:53:02 -0700
Subject: RFR(XS): 8043063: Code aging should allocate MethodCounters when
	flushing a method
In-Reply-To: <5372CE77.6090900@oracle.com>
References: <5D2F008F-0CA5-48AB-A93E-3F1377CC8871@oracle.com>	<5372C025.3070504@oracle.com>
	<A63840E5-9718-4BF0-B35B-E77301DC5760@oracle.com>
	<5372CE77.6090900@oracle.com>
Message-ID: <60FF70A7-4D26-4215-BD10-82CB7B405E3E@oracle.com>

Thanks, Vladimir!

igor

On May 13, 2014, at 7:01 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> On 5/13/14 6:14 PM, Igor Veresov wrote:
>> I don?t think it hurts to make sure they exist at this point in the sweeper. In addition to that, only AdvancedTieredPolicy needs them to be present if a method in the queue. Other policies could work fine without MCs, and for example with Xcomp. It would be needless to allocate MCs in that case.
> 
> Okay. Changes are good.
> 
> thanks,
> Vladimir
> 
>> 
>> igor
>> 
>> On May 13, 2014, at 6:00 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> I think this should be fixed in general (8043061). We should allocate MethodCounters at least when we create a compilation task.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 5/13/14 5:45 PM, Igor Veresov wrote:
>>>> In some edge cases we may not have MethodCounters allocated for a method that was compiled, like with -Xcomp.
>>>> So with code aging we need to allocate MCs when we are flushing the method to set up the aging counter.
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043063/webrev.00/
>>>> 
>>>> Thanks!
>>>> igor
>>>> 
>> 


From igor.veresov at oracle.com  Wed May 14 03:53:15 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 13 May 2014 20:53:15 -0700
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't
	enter safepoint
In-Reply-To: <5372CD55.60904@oracle.com>
References: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
	<5372CD55.60904@oracle.com>
Message-ID: <A1A76F62-B0CF-460E-BB36-378914D9FD64@oracle.com>

Thank you!

igor

On May 13, 2014, at 6:56 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Good.
> 
> Vladimir
> 
> On 5/13/14 6:11 PM, Igor Veresov wrote:
>> nmethod::verify_interrupt_point() is called from as part of nmethod verification from ciEnv::register_method() that asserts no safepoint can occur. However verify_interrupt_point() locks a mutex that may potentially safepoint. A sample call stack of when it happens is in the following JBS issue.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070
>> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/
>> 
>> igor
>> 


From staffan.larsen at oracle.com  Wed May 14 06:58:13 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 14 May 2014 08:58:13 +0200
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with
	assert(_cur_stack_depth == count_frames()) failed:
	cur_stack_depth out of sync
In-Reply-To: <A6074FC1-35DD-4672-AB1C-020C2961CD55@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>	<536BB959.7060706@oracle.com>
	<2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>
	<536D1BDC.7000908@oracle.com>
	<C6B702AE-DCB5-4E11-8879-D8540E3E969A@oracle.com>
	<53724E17.2080406@oracle.com>
	<5B0A0E2F-FD3C-47D1-85C5-0B4470FC4F9D@oracle.com>
	<A6074FC1-35DD-4672-AB1C-020C2961CD55@oracle.com>
Message-ID: <3B477FDF-002F-429D-92CF-314F9A42C22A@oracle.com>

Thanks Christian,

I will make the change below before I push.

/Staffan


diff --git a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp
--- a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp
+++ b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp
@@ -2248,7 +2248,7 @@
     // if we are now in interp_only_mode and in that case we do the jvmti
     // callback.
     Label skip_jvmti_method_exit;
-    __ cmpb(Address(thread, JavaThread::interp_only_mode_offset()), 0);
+    __ cmpl(Address(thread, JavaThread::interp_only_mode_offset()), 0);
     __ jcc(Assembler::zero, skip_jvmti_method_exit, true);

     save_native_result(masm, ret_type, stack_slots);
diff --git a/src/cpu/x86/vm/sharedRuntime_x86_64.cpp b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp
--- a/src/cpu/x86/vm/sharedRuntime_x86_64.cpp
+++ b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp
@@ -2495,7 +2495,7 @@
     // if we are now in interp_only_mode and in that case we do the jvmti
     // callback.
     Label skip_jvmti_method_exit;
-    __ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0);
+    __ cmpl(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0);
     __ jcc(Assembler::zero, skip_jvmti_method_exit, true);

     save_native_result(masm, ret_type, stack_slots);


On 14 maj 2014, at 00:21, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> Since:
> 
>   int               _interp_only_mode;
> 
> is an int field I would prefer to actually read the value as an int instead of just a byte on x86:
> +    __ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0);
> Otherwise this looks good.
> 
> On May 13, 2014, at 11:30 AM, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
>> 
>> On 13 maj 2014, at 18:53, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>> 
>>> > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/
>>> 
>>> src/share/vm/runtime/sharedRuntime.hpp
>>>     No comments.
>>> 
>>> src/share/vm/runtime/sharedRuntime.cpp
>>>     No comments.
>>> 
>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>>     No comments.
>>> 
>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>>     No comments.
>>> 
>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>>     No comments.
>>> 
>>> On the switch from call_VM_leaf() -> call_VM(), I looked through all
>>> the mentions of the string call_VM in the three src/cpu files. Your
>>> change adds the first call_VM() use in all three files and the other
>>> places that mention the string "call_VM" seem to have gone through
>>> a great deal of trouble not to use call_VM() directly. I have no
>>> specific thing I think is wrong, but I find this data worrisome?
>> 
>> Yes, it would be great if someone from the compiler team could review this, too.
>> 
>> Thanks,
>> /Staffan
>> 
>>> 
>>> Thumbs up!
>>> 
>>> Dan
>>> 
>>> 
>>> On 5/13/14 3:20 AM, Staffan Larsen wrote:
>>>> 
>>>> On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com wrote:
>>>> 
>>>>> Staffan,
>>>>> 
>>>>> This is important discovery, thanks!
>>>>> The fix looks good to me.
>>>>> One question below.
>>>>> 
>>>>> Thanks,
>>>>> Serguei
>>>>> 
>>>>> 
>>>>> On 5/9/14 3:47 AM, Staffan Larsen wrote:
>>>>>> On 8 maj 2014, at 19:05, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>>>>> 
>>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>>>>> src/share/vm/runtime/sharedRuntime.hpp
>>>>>>>    No comments.
>>>>>>> 
>>>>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>>>>>    line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit(
>>>>>>>        I'm not sure that JRT_LEAF is right. I would think that
>>>>>>>        JvmtiExport::post_method_exit() would have to grab one or
>>>>>>>        more locks with all the state checks it has to make...
>>>>>>> 
>>>>>>>        For reference, InterpreterRuntime::post_method_exit()
>>>>>>>        is a wrapper around JvmtiExport::post_method_exit()
>>>>>>>        and it is IRT_ENTRY instead of IRT_LEAF.
>>>>>> Good catch!
>>>>> 
>>>>> Q: Is correct to use call_VM_leaf (vs call_VM ) in the  sharedRuntime_<arch>.cpp ?
>>>>> 
>>>>> +    __ call_VM_leaf(
>>>>> +         CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit),
>>>>> +         thread, rax);
>>>> 
>>>> That is another good catch! It should probably be call_VM as you note. The reason for all these leaf references is because we used the dtrace probe as a template - obviously without fully understanding what we did :-/
>>>> 
>>>> I have changed to code to use call_VM instead. This also required a change from jccb to jcc for the jump (which is now longer than an 8-bit offset). 
>>>> 
>>>> new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/
>>>> 
>>>> Thanks,
>>>> /Staffan
>>>> 
>>>> 
>>>>> 
>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>>>>>>    No comments.
>>>>>>> 
>>>>>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>>>>>>    No comments.
>>>>>>> 
>>>>>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>>>>>>    No comments.
>>>>>>> 
>>>>>>> I'm guessing that PPC has the same issue, but I'm presuming
>>>>>>> that someone else (Vladimir?) will handle that?
>>>>>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix.
>>>>>> 
>>>>>> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/
>>>>>> 
>>>>>> Thanks,
>>>>>> /Staffan
>>>>>> 
>>>>>>> Dan
>>>>>>> 
>>>>>>> 
>>>>>>> On 5/8/14 12:06 AM, Staffan Larsen wrote:
>>>>>>>> All,
>>>>>>>> 
>>>>>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
>>>>>>>> 
>>>>>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
>>>>>>>> 
>>>>>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
>>>>>>>> 
>>>>>>>> Kudos to Rickard for helping me write the code.
>>>>>>>> 
>>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934
>>>>>>>> 
>>>>>>>> The fix has been verified by running the failing test in JPRT with -Xcomp.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> /Staffan
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140514/70111ebc/attachment-0001.html>

From mikael.gerdin at oracle.com  Wed May 14 07:04:40 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 14 May 2014 09:04:40 +0200
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't
	enter safepoint
In-Reply-To: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
References: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
Message-ID: <1705870.2PoW2RCLHj@mgerdin-lap>

Igor,

On Tuesday 13 May 2014 18.11.48 Igor Veresov wrote:
> nmethod::verify_interrupt_point() is called from as part of nmethod
> verification from ciEnv::register_method() that asserts no safepoint can
> occur. However verify_interrupt_point() locks a mutex that may potentially
> safepoint. A sample call stack of when it happens is in the following JBS
> issue.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070
> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/

It's unsafe to mix safepoint-aware and safepoint-ignoring locking on a single 
Mutex as that can deadlock the VM, see 
https://bugs.openjdk.java.net/browse/JDK-8039458

CompiledIC_lock is taken without _no_safepoint_check_flag at all other uses.

/Mikael

> 
> igor


From igor.veresov at oracle.com  Wed May 14 07:39:58 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 14 May 2014 00:39:58 -0700
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't
	enter safepoint
In-Reply-To: <1705870.2PoW2RCLHj@mgerdin-lap>
References: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
	<1705870.2PoW2RCLHj@mgerdin-lap>
Message-ID: <AE09FF0F-CEC5-43FD-ACB0-E30BC6D32075@oracle.com>

Mikael,

I agree it?s ugly and we have to rethink the code management locks, but it?s only dangerous if there is a safepoint-cooperating lock within the scope of this one. There isn?t any, so I assume it should be safe. Right?

igor
 
On May 14, 2014, at 12:04 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:

> Igor,
> 
> On Tuesday 13 May 2014 18.11.48 Igor Veresov wrote:
>> nmethod::verify_interrupt_point() is called from as part of nmethod
>> verification from ciEnv::register_method() that asserts no safepoint can
>> occur. However verify_interrupt_point() locks a mutex that may potentially
>> safepoint. A sample call stack of when it happens is in the following JBS
>> issue.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070
>> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/
> 
> It's unsafe to mix safepoint-aware and safepoint-ignoring locking on a single 
> Mutex as that can deadlock the VM, see 
> https://bugs.openjdk.java.net/browse/JDK-8039458
> 
> CompiledIC_lock is taken without _no_safepoint_check_flag at all other uses.
> 
> /Mikael
> 
>> 
>> igor
> 


From igor.veresov at oracle.com  Wed May 14 08:35:46 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 14 May 2014 01:35:46 -0700
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't
	enter safepoint
In-Reply-To: <AE09FF0F-CEC5-43FD-ACB0-E30BC6D32075@oracle.com>
References: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
	<1705870.2PoW2RCLHj@mgerdin-lap>
	<AE09FF0F-CEC5-43FD-ACB0-E30BC6D32075@oracle.com>
Message-ID: <6B76419A-328B-4D00-A8BF-FA9E5AEBD220@oracle.com>

Would it be better if I assert that we don?t ever enter a safepoint in that scope?
http://cr.openjdk.java.net/~iveresov/8043070/webrev.01/

igor


On May 14, 2014, at 12:39 AM, Igor Veresov <igor.veresov at oracle.com> wrote:

> Mikael,
> 
> I agree it?s ugly and we have to rethink the code management locks, but it?s only dangerous if there is a safepoint-cooperating lock within the scope of this one. There isn?t any, so I assume it should be safe. Right?
> 
> igor
> 
> On May 14, 2014, at 12:04 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
> 
>> Igor,
>> 
>> On Tuesday 13 May 2014 18.11.48 Igor Veresov wrote:
>>> nmethod::verify_interrupt_point() is called from as part of nmethod
>>> verification from ciEnv::register_method() that asserts no safepoint can
>>> occur. However verify_interrupt_point() locks a mutex that may potentially
>>> safepoint. A sample call stack of when it happens is in the following JBS
>>> issue.
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070
>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/
>> 
>> It's unsafe to mix safepoint-aware and safepoint-ignoring locking on a single 
>> Mutex as that can deadlock the VM, see 
>> https://bugs.openjdk.java.net/browse/JDK-8039458
>> 
>> CompiledIC_lock is taken without _no_safepoint_check_flag at all other uses.
>> 
>> /Mikael
>> 
>>> 
>>> igor
>> 
> 


From mikael.gerdin at oracle.com  Wed May 14 09:23:22 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 14 May 2014 11:23:22 +0200
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't
	enter safepoint
In-Reply-To: <6B76419A-328B-4D00-A8BF-FA9E5AEBD220@oracle.com>
References: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
	<AE09FF0F-CEC5-43FD-ACB0-E30BC6D32075@oracle.com>
	<6B76419A-328B-4D00-A8BF-FA9E5AEBD220@oracle.com>
Message-ID: <1679027.HDHsSq8pUN@mgerdin03>

Igor,

On Wednesday 14 May 2014 01.35.46 Igor Veresov wrote:
> Would it be better if I assert that we don?t ever enter a safepoint in that
> scope? http://cr.openjdk.java.net/~iveresov/8043070/webrev.01/

Actually, I realized that Markus' bug is not the issue I thought it was.
What I meant was something similar to this bug which I fixed a while back:
https://bugs.openjdk.java.net/browse/JDK-8013129

Unfortunately I was scarce with details about the deadlock so I'm going to 
backout the change and try to reproduce the deadlock to see the exact steps it 
took to provoke it.

/Mikael

> 
> igor
> 
> On May 14, 2014, at 12:39 AM, Igor Veresov <igor.veresov at oracle.com> wrote:
> > Mikael,
> > 
> > I agree it?s ugly and we have to rethink the code management locks, but
> > it?s only dangerous if there is a safepoint-cooperating lock within the
> > scope of this one. There isn?t any, so I assume it should be safe. Right?
> > 
> > igor
> > 
> > On May 14, 2014, at 12:04 AM, Mikael Gerdin <mikael.gerdin at oracle.com> 
wrote:
> >> Igor,
> >> 
> >> On Tuesday 13 May 2014 18.11.48 Igor Veresov wrote:
> >>> nmethod::verify_interrupt_point() is called from as part of nmethod
> >>> verification from ciEnv::register_method() that asserts no safepoint can
> >>> occur. However verify_interrupt_point() locks a mutex that may
> >>> potentially
> >>> safepoint. A sample call stack of when it happens is in the following
> >>> JBS
> >>> issue.
> >>> 
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070
> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/
> >> 
> >> It's unsafe to mix safepoint-aware and safepoint-ignoring locking on a
> >> single Mutex as that can deadlock the VM, see
> >> https://bugs.openjdk.java.net/browse/JDK-8039458
> >> 
> >> CompiledIC_lock is taken without _no_safepoint_check_flag at all other
> >> uses.
> >> 
> >> /Mikael
> >> 
> >>> igor


From mikael.gerdin at oracle.com  Wed May 14 11:20:41 2014
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Wed, 14 May 2014 13:20:41 +0200
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't
	enter safepoint
In-Reply-To: <1679027.HDHsSq8pUN@mgerdin03>
References: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
	<6B76419A-328B-4D00-A8BF-FA9E5AEBD220@oracle.com>
	<1679027.HDHsSq8pUN@mgerdin03>
Message-ID: <7613371.caJJoI3tB6@mgerdin03>

On Wednesday 14 May 2014 11.23.22 Mikael Gerdin wrote:
> Igor,
> 
> On Wednesday 14 May 2014 01.35.46 Igor Veresov wrote:
> > Would it be better if I assert that we don?t ever enter a safepoint in
> > that
> > scope? http://cr.openjdk.java.net/~iveresov/8043070/webrev.01/
> 
> Actually, I realized that Markus' bug is not the issue I thought it was.
> What I meant was something similar to this bug which I fixed a while back:
> https://bugs.openjdk.java.net/browse/JDK-8013129
> 
> Unfortunately I was scarce with details about the deadlock so I'm going to
> backout the change and try to reproduce the deadlock to see the exact steps
> it took to provoke it.

I managed to reproduce my earlier problem with mixing _no_safepoint_check_flag 
on a single lock, here's how this can deadlock:

T1 is initiating a safepoint (for whatever reason)
T2 is parked in Monitor::lock_without_safepoint_check -> Monitor::ILock
T3 has returned from ILock in Monitor::lock and catches the safepoint in 
~ThreadBlockInVM

T2 will never reach the safepoint since it's blocking while _vm_running

I've updated https://bugs.openjdk.java.net/browse/JDK-8013129 with a stack 
trace from a deadlocked VM.

/Mikael

> 
> /Mikael
> 
> > igor
> > 
> > On May 14, 2014, at 12:39 AM, Igor Veresov <igor.veresov at oracle.com> 
wrote:
> > > Mikael,
> > > 
> > > I agree it?s ugly and we have to rethink the code management locks, but
> > > it?s only dangerous if there is a safepoint-cooperating lock within the
> > > scope of this one. There isn?t any, so I assume it should be safe.
> > > Right?
> > > 
> > > igor
> > > 
> > > On May 14, 2014, at 12:04 AM, Mikael Gerdin <mikael.gerdin at oracle.com>
> 
> wrote:
> > >> Igor,
> > >> 
> > >> On Tuesday 13 May 2014 18.11.48 Igor Veresov wrote:
> > >>> nmethod::verify_interrupt_point() is called from as part of nmethod
> > >>> verification from ciEnv::register_method() that asserts no safepoint
> > >>> can
> > >>> occur. However verify_interrupt_point() locks a mutex that may
> > >>> potentially
> > >>> safepoint. A sample call stack of when it happens is in the following
> > >>> JBS
> > >>> issue.
> > >>> 
> > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070
> > >>> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/
> > >> 
> > >> It's unsafe to mix safepoint-aware and safepoint-ignoring locking on a
> > >> single Mutex as that can deadlock the VM, see
> > >> https://bugs.openjdk.java.net/browse/JDK-8039458
> > >> 
> > >> CompiledIC_lock is taken without _no_safepoint_check_flag at all other
> > >> uses.
> > >> 
> > >> /Mikael
> > >> 
> > >>> igor


From filipp.zhinkin at oracle.com  Wed May 14 15:02:23 2014
From: filipp.zhinkin at oracle.com (Filipp Zhinkin)
Date: Wed, 14 May 2014 19:02:23 +0400
Subject: [8u20] RFR (XS): JDK-8042949: +UnlockExperimentalVMOptions missed
	from TestUseRTMLockingOptionOnUnsupportedVM.java test
In-Reply-To: <53726E8F.8060700@oracle.com>
References: <53726B5B.6050504@oracle.com> <53726E8F.8060700@oracle.com>
Message-ID: <5373857F.7060706@oracle.com>

Vladimir, thank you.

Filipp.

On 05/13/2014 11:12 PM, Vladimir Kozlov wrote:
> Looks good.
>
> Thanks,
> Vladimir
>
> On 5/13/14 11:58 AM, Filipp Zhinkin wrote:
>> Hi,
>>
>> I'd like to fix small issue with TestUseRTMLockingOptionOnUnsupportedVM
>> test.
>>
>> While backporting it from 9 to 8u20 I forgot to add
>> +UnlockExperimentalVMOptionand test fails.Now I'm going to add missed 
>> flag.
>>
>> Fix applicable only for 8u20, because in JDK 9 UseRTMLocking is product
>> flag,
>> while in 8u20 it is experimental.
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~iignatyev/fzhinkin/8042949/webrev.00/
>> Testing done: manual and automated.
>>
>> Thanks,
>> Filipp.


From roland.westrelin at oracle.com  Wed May 14 16:16:32 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 14 May 2014 18:16:32 +0200
Subject: RFR(S): 8026694: New type profiling points break compilation
	replay
In-Reply-To: <6964A332-4840-4A48-AD90-952679F9B212@oracle.com>
References: <E20FFE87-2103-4CF7-842B-28B978F5B5B4@oracle.com>	<052582DD-754A-419C-AE35-F805B6CF300B@oracle.com>	<5346D747.60006@oracle.com>	<96AE8801-26D7-45F8-AF5A-3222EA0FD996@oracle.com>	<534D754E.2020804@oracle.com>	<58C7436F-3647-43CA-B626-1ADC4B433BF4@oracle.com>
	<534D7F58.4080904@oracle.com> <534DAB2B.7000402@oracle.com>
	<979681E8-95E3-4977-8688-E576DCC0C117@oracle.com>
	<6964A332-4840-4A48-AD90-952679F9B212@oracle.com>
Message-ID: <C5234317-8A5E-4BEA-B618-44E25EBCC53F@oracle.com>

> src/share/vm/ci/ciReplay.cpp:
> 
> !   Klass**   _classes_handles;
> !   Method**  _methods_handles;
> 
> Remove the _handles suffix because it?s not that case anymore.

I will make that change.

> Otherwise this looks good.

Thanks for the review, Christian.

Following, the fix for "8032463: VirtualDispatch test timeout with DeoptimizeALot?, the change below is also required:

diff --git a/src/share/vm/runtime/vmStructs.cpp b/src/share/vm/runtime/vmStructs.cpp
--- a/src/share/vm/runtime/vmStructs.cpp
+++ b/src/share/vm/runtime/vmStructs.cpp
@@ -2503,6 +2503,7 @@
   declare_constant(Deoptimization::Reason_speculate_class_check)          \
   declare_constant(Deoptimization::Reason_speculate_null_check)           \
   declare_constant(Deoptimization::Reason_rtm_state_change)               \
+  declare_constant(Deoptimization::Reason_tenured)                        \
   declare_constant(Deoptimization::Reason_LIMIT)                          \
   declare_constant(Deoptimization::Reason_RECORDED_LIMIT)                 \
                                                                           \
No objection that I push this small fix with the rest?

Roland.


> 
> On Apr 18, 2014, at 2:33 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
> 
>> 
>> Here a new webrev with the SA support:
>> 
>> http://cr.openjdk.java.net/~roland/8026694/webrev.01/
>> 
>> The ciReplay jtreg tests now pass.
>> 
>> Roland.
>> 
>> 
>> On Apr 15, 2014, at 11:56 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> Roland,
>>> 
>>> Can you look on compiler/ciReplay/TestSA.sh failure? Is it because of additional metadata?  Will this your change fix it? Do you need to update SA too?
>>> 
>>> I got next running latest promoted jdk9 fastdebug VM with Tiered off:
>>> 
>>> WARNING: replay.txt from SA != replay.txt from VM:
>>> 
>>> < # ciMetadata0 @ sun.jvm.hotspot.oops.TypeArrayKlass at 0x0000000100000030
>>> < # Unknown ci type 0xfffffd7ed7ecc5a0
>>> ...
>>> < # ciMetadata98 @ sun.jvm.hotspot.oops.Method at 0xfffffd7ffccf9da0
>>> 504a396,403
>>>> ciMethodData java/lang/invoke/MethodHandle <clinit> ()V 1 0 orig 304 104 155 245 215 126 253 255 255 0 0 0 0 0 0 0 0 240 46 198 252 127 253 255 255 208 2 0 0
>>> 
>>> And:
>>> 
>>> Exception in thread "main" java.lang.InternalError: missing reason for 17
>>>       at sun.jvm.hotspot.oops.MethodData.initialize(MethodData.java:185)
>>>       at sun.jvm.hotspot.oops.MethodData.access$000(MethodData.java:36)
>>>       at sun.jvm.hotspot.oops.MethodData$1.update(MethodData.java:126)
>>>       at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394)
>>>       at sun.jvm.hotspot.oops.MethodData.<clinit>(MethodData.java:124)
>>> 
>>> thanks,
>>> Vladimir
>>> 
>>> On 4/15/14 11:50 AM, Vladimir Kozlov wrote:
>>>> On 4/15/14 11:21 AM, Roland Westrelin wrote:
>>>>>>>>>> http://cr.openjdk.java.net/~roland/8026694/webrev.00/
>>>>>>>>>> 
>>>>>>>>>> If we want to still be able to read replay files generated before
>>>>>>>>>> this change, the assert:
>>>>>>>>>> 
>>>>>>>>>> src/share/vm/ci/ciReplay.cpp
>>>>>>>>>> 1120       assert(m->_data_size + m->_extra_data_size ==
>>>>>>>>>> rec->_data_length * (int)sizeof(rec->_data[0]), "must agree?);
>>>>>>>>>> 
>>>>>>>>>> needs to removed or changed (extra data from the MDO is not
>>>>>>>>>> currently dumped).
>>>>>>>> 
>>>>>>>> Are you asking what to do with the assert? Can you detect if replay
>>>>>>>> file has extra data?
>>>>>>> 
>>>>>>> I can change the assert to:
>>>>>>> 
>>>>>>>      assert(m->_data_size + m->_extra_data_size ==
>>>>>>> rec->_data_length * (int)sizeof(rec->_data[0]) ||
>>>>>>>             m->_data_size == rec->_data_length *
>>>>>>> (int)sizeof(rec->_data[0]), "must agree?);
>>>>>>> 
>>>>>>> and then it covers both cases. There?s no real need to detect
>>>>>>> whether the replay file has extra data.
>>>>>> 
>>>>>> Agree.
>>>>> 
>>>>> Thanks Vladimir. Can I consider this reviewed?
>>>> 
>>>> Yes.
>>>> 
>>>> Vladimir
>>>> 
>>>>> 
>>>>> Roland.
>>>>> 
>> 
> 


From Kirill.Shirokov at Oracle.COM  Wed May 14 16:29:09 2014
From: Kirill.Shirokov at Oracle.COM (Kirill Shirokov)
Date: Wed, 14 May 2014 20:29:09 +0400
Subject: Request for review: JDK-8032970: stack size check methods for
	WhiteBox API
In-Reply-To: <52F12B6B.1000303@oracle.com>
References: <52F0F609.3000108@oracle.com> <52F0FC77.709@oracle.com>
	<52F12B6B.1000303@oracle.com>
Message-ID: <537399D5.5040807@Oracle.COM>

Thanks to all reviewers!

Could I ask to reivew the fixed patch:
http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.03/

Bug report:
https://bugs.openjdk.java.net/browse/JDK-8032970

The new functions will be used in the existing JSR292 tests -- we see a 
lot of failures due to StackOverflowError.

Best regards,
Kirill

On 02/04/2014 10:03 PM, Vladimir Kozlov wrote:
> Kirill,
>
> You should include link to the bug report and add more explanation 
> what this changes for. Will new functions be used in new or existing 
> jsr292 tests?
>
> test/testlibrary_tests directory is used for classes used by other 
> tests. I think you need to move new test WBStackSize.java into 
> test/runtime directory.
>
> Thanks,
> Vladimir
>
> On 2/4/14 6:43 AM, Kirill Shirokov wrote:
>> Hi,
>>
>> Please review following webrev, which adds stack size checking methods
>> to WhiteBox API:
>>
>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.00/
>> <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.00/>
>>
>> Thank you,
>> Kirill
>>
>>
>>


From vladimir.kozlov at oracle.com  Wed May 14 16:54:06 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 14 May 2014 09:54:06 -0700
Subject: RFR(S): 8026694: New type profiling points break compilation
	replay
In-Reply-To: <C5234317-8A5E-4BEA-B618-44E25EBCC53F@oracle.com>
References: <E20FFE87-2103-4CF7-842B-28B978F5B5B4@oracle.com>	<052582DD-754A-419C-AE35-F805B6CF300B@oracle.com>	<5346D747.60006@oracle.com>	<96AE8801-26D7-45F8-AF5A-3222EA0FD996@oracle.com>	<534D754E.2020804@oracle.com>	<58C7436F-3647-43CA-B626-1ADC4B433BF4@oracle.com>	<534D7F58.4080904@oracle.com>
	<534DAB2B.7000402@oracle.com>	<979681E8-95E3-4977-8688-E576DCC0C117@oracle.com>	<6964A332-4840-4A48-AD90-952679F9B212@oracle.com>
	<C5234317-8A5E-4BEA-B618-44E25EBCC53F@oracle.com>
Message-ID: <53739FAE.8070500@oracle.com>

Ship it.

Vladimir

On 5/14/14 9:16 AM, Roland Westrelin wrote:
>> src/share/vm/ci/ciReplay.cpp:
>>
>> !   Klass**   _classes_handles;
>> !   Method**  _methods_handles;
>>
>> Remove the _handles suffix because it?s not that case anymore.
>
> I will make that change.
>
>> Otherwise this looks good.
>
> Thanks for the review, Christian.
>
> Following, the fix for "8032463: VirtualDispatch test timeout with DeoptimizeALot?, the change below is also required:
>
> diff --git a/src/share/vm/runtime/vmStructs.cpp b/src/share/vm/runtime/vmStructs.cpp
> --- a/src/share/vm/runtime/vmStructs.cpp
> +++ b/src/share/vm/runtime/vmStructs.cpp
> @@ -2503,6 +2503,7 @@
>     declare_constant(Deoptimization::Reason_speculate_class_check)          \
>     declare_constant(Deoptimization::Reason_speculate_null_check)           \
>     declare_constant(Deoptimization::Reason_rtm_state_change)               \
> +  declare_constant(Deoptimization::Reason_tenured)                        \
>     declare_constant(Deoptimization::Reason_LIMIT)                          \
>     declare_constant(Deoptimization::Reason_RECORDED_LIMIT)                 \
>                                                                             \
> No objection that I push this small fix with the rest?
>
> Roland.
>
>
>>
>> On Apr 18, 2014, at 2:33 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
>>
>>>
>>> Here a new webrev with the SA support:
>>>
>>> http://cr.openjdk.java.net/~roland/8026694/webrev.01/
>>>
>>> The ciReplay jtreg tests now pass.
>>>
>>> Roland.
>>>
>>>
>>> On Apr 15, 2014, at 11:56 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>
>>>> Roland,
>>>>
>>>> Can you look on compiler/ciReplay/TestSA.sh failure? Is it because of additional metadata?  Will this your change fix it? Do you need to update SA too?
>>>>
>>>> I got next running latest promoted jdk9 fastdebug VM with Tiered off:
>>>>
>>>> WARNING: replay.txt from SA != replay.txt from VM:
>>>>
>>>> < # ciMetadata0 @ sun.jvm.hotspot.oops.TypeArrayKlass at 0x0000000100000030
>>>> < # Unknown ci type 0xfffffd7ed7ecc5a0
>>>> ...
>>>> < # ciMetadata98 @ sun.jvm.hotspot.oops.Method at 0xfffffd7ffccf9da0
>>>> 504a396,403
>>>>> ciMethodData java/lang/invoke/MethodHandle <clinit> ()V 1 0 orig 304 104 155 245 215 126 253 255 255 0 0 0 0 0 0 0 0 240 46 198 252 127 253 255 255 208 2 0 0
>>>>
>>>> And:
>>>>
>>>> Exception in thread "main" java.lang.InternalError: missing reason for 17
>>>>        at sun.jvm.hotspot.oops.MethodData.initialize(MethodData.java:185)
>>>>        at sun.jvm.hotspot.oops.MethodData.access$000(MethodData.java:36)
>>>>        at sun.jvm.hotspot.oops.MethodData$1.update(MethodData.java:126)
>>>>        at sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:394)
>>>>        at sun.jvm.hotspot.oops.MethodData.<clinit>(MethodData.java:124)
>>>>
>>>> thanks,
>>>> Vladimir
>>>>
>>>> On 4/15/14 11:50 AM, Vladimir Kozlov wrote:
>>>>> On 4/15/14 11:21 AM, Roland Westrelin wrote:
>>>>>>>>>>> http://cr.openjdk.java.net/~roland/8026694/webrev.00/
>>>>>>>>>>>
>>>>>>>>>>> If we want to still be able to read replay files generated before
>>>>>>>>>>> this change, the assert:
>>>>>>>>>>>
>>>>>>>>>>> src/share/vm/ci/ciReplay.cpp
>>>>>>>>>>> 1120       assert(m->_data_size + m->_extra_data_size ==
>>>>>>>>>>> rec->_data_length * (int)sizeof(rec->_data[0]), "must agree?);
>>>>>>>>>>>
>>>>>>>>>>> needs to removed or changed (extra data from the MDO is not
>>>>>>>>>>> currently dumped).
>>>>>>>>>
>>>>>>>>> Are you asking what to do with the assert? Can you detect if replay
>>>>>>>>> file has extra data?
>>>>>>>>
>>>>>>>> I can change the assert to:
>>>>>>>>
>>>>>>>>       assert(m->_data_size + m->_extra_data_size ==
>>>>>>>> rec->_data_length * (int)sizeof(rec->_data[0]) ||
>>>>>>>>              m->_data_size == rec->_data_length *
>>>>>>>> (int)sizeof(rec->_data[0]), "must agree?);
>>>>>>>>
>>>>>>>> and then it covers both cases. There?s no real need to detect
>>>>>>>> whether the replay file has extra data.
>>>>>>>
>>>>>>> Agree.
>>>>>>
>>>>>> Thanks Vladimir. Can I consider this reviewed?
>>>>>
>>>>> Yes.
>>>>>
>>>>> Vladimir
>>>>>
>>>>>>
>>>>>> Roland.
>>>>>>
>>>
>>
>

From christian.thalinger at oracle.com  Wed May 14 18:30:54 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 14 May 2014 11:30:54 -0700
Subject: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with
	assert(_cur_stack_depth == count_frames()) failed:
	cur_stack_depth out of sync
In-Reply-To: <3B477FDF-002F-429D-92CF-314F9A42C22A@oracle.com>
References: <8A4571CD-37D1-41BF-AC79-30853BF1C305@oracle.com>	<536BB959.7060706@oracle.com>
	<2E48F010-CE96-4676-8763-E801CBCF5D00@oracle.com>
	<536D1BDC.7000908@oracle.com>
	<C6B702AE-DCB5-4E11-8879-D8540E3E969A@oracle.com>
	<53724E17.2080406@oracle.com>
	<5B0A0E2F-FD3C-47D1-85C5-0B4470FC4F9D@oracle.com>
	<A6074FC1-35DD-4672-AB1C-020C2961CD55@oracle.com>
	<3B477FDF-002F-429D-92CF-314F9A42C22A@oracle.com>
Message-ID: <ECB36303-8D90-4812-ADED-09ABDF3E0DA3@oracle.com>

Looks good.

On May 13, 2014, at 11:58 PM, Staffan Larsen <staffan.larsen at oracle.com> wrote:

> Thanks Christian,
> 
> I will make the change below before I push.
> 
> /Staffan
> 
> 
> diff --git a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp
> --- a/src/cpu/x86/vm/sharedRuntime_x86_32.cpp
> +++ b/src/cpu/x86/vm/sharedRuntime_x86_32.cpp
> @@ -2248,7 +2248,7 @@
>      // if we are now in interp_only_mode and in that case we do the jvmti
>      // callback.
>      Label skip_jvmti_method_exit;
> -    __ cmpb(Address(thread, JavaThread::interp_only_mode_offset()), 0);
> +    __ cmpl(Address(thread, JavaThread::interp_only_mode_offset()), 0);
>      __ jcc(Assembler::zero, skip_jvmti_method_exit, true);
> 
>      save_native_result(masm, ret_type, stack_slots);
> diff --git a/src/cpu/x86/vm/sharedRuntime_x86_64.cpp b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp
> --- a/src/cpu/x86/vm/sharedRuntime_x86_64.cpp
> +++ b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp
> @@ -2495,7 +2495,7 @@
>      // if we are now in interp_only_mode and in that case we do the jvmti
>      // callback.
>      Label skip_jvmti_method_exit;
> -    __ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0);
> +    __ cmpl(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0);
>      __ jcc(Assembler::zero, skip_jvmti_method_exit, true);
> 
>      save_native_result(masm, ret_type, stack_slots);
> 
> 
> On 14 maj 2014, at 00:21, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> Since:
>> 
>>   int               _interp_only_mode;
>> 
>> is an int field I would prefer to actually read the value as an int instead of just a byte on x86:
>> +    __ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0);
>> Otherwise this looks good.
>> 
>> On May 13, 2014, at 11:30 AM, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>> 
>>> 
>>> On 13 maj 2014, at 18:53, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>> 
>>>> > new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/
>>>> 
>>>> src/share/vm/runtime/sharedRuntime.hpp
>>>>     No comments.
>>>> 
>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>>     No comments.
>>>> 
>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>>>     No comments.
>>>> 
>>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>>>     No comments.
>>>> 
>>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>>>     No comments.
>>>> 
>>>> On the switch from call_VM_leaf() -> call_VM(), I looked through all
>>>> the mentions of the string call_VM in the three src/cpu files. Your
>>>> change adds the first call_VM() use in all three files and the other
>>>> places that mention the string "call_VM" seem to have gone through
>>>> a great deal of trouble not to use call_VM() directly. I have no
>>>> specific thing I think is wrong, but I find this data worrisome?
>>> 
>>> Yes, it would be great if someone from the compiler team could review this, too.
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>>> 
>>>> Thumbs up!
>>>> 
>>>> Dan
>>>> 
>>>> 
>>>> On 5/13/14 3:20 AM, Staffan Larsen wrote:
>>>>> 
>>>>> On 9 maj 2014, at 20:18, serguei.spitsyn at oracle.com wrote:
>>>>> 
>>>>>> Staffan,
>>>>>> 
>>>>>> This is important discovery, thanks!
>>>>>> The fix looks good to me.
>>>>>> One question below.
>>>>>> 
>>>>>> Thanks,
>>>>>> Serguei
>>>>>> 
>>>>>> 
>>>>>> On 5/9/14 3:47 AM, Staffan Larsen wrote:
>>>>>>> On 8 maj 2014, at 19:05, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>>>>>> 
>>>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>>>>>> src/share/vm/runtime/sharedRuntime.hpp
>>>>>>>>    No comments.
>>>>>>>> 
>>>>>>>> src/share/vm/runtime/sharedRuntime.cpp
>>>>>>>>    line 994: JRT_LEAF(int, SharedRuntime::jvmti_method_exit(
>>>>>>>>        I'm not sure that JRT_LEAF is right. I would think that
>>>>>>>>        JvmtiExport::post_method_exit() would have to grab one or
>>>>>>>>        more locks with all the state checks it has to make...
>>>>>>>> 
>>>>>>>>        For reference, InterpreterRuntime::post_method_exit()
>>>>>>>>        is a wrapper around JvmtiExport::post_method_exit()
>>>>>>>>        and it is IRT_ENTRY instead of IRT_LEAF.
>>>>>>> Good catch!
>>>>>> 
>>>>>> Q: Is correct to use call_VM_leaf (vs call_VM ) in the  sharedRuntime_<arch>.cpp ?
>>>>>> 
>>>>>> +    __ call_VM_leaf(
>>>>>> +         CAST_FROM_FN_PTR(address, SharedRuntime::jvmti_method_exit),
>>>>>> +         thread, rax);
>>>>> 
>>>>> That is another good catch! It should probably be call_VM as you note. The reason for all these leaf references is because we used the dtrace probe as a template - obviously without fully understanding what we did :-/
>>>>> 
>>>>> I have changed to code to use call_VM instead. This also required a change from jccb to jcc for the jump (which is now longer than an 8-bit offset). 
>>>>> 
>>>>> new webrev is here: http://cr.openjdk.java.net/~sla/8041934/webrev.02/
>>>>> 
>>>>> Thanks,
>>>>> /Staffan
>>>>> 
>>>>> 
>>>>>> 
>>>>>>>> src/cpu/sparc/vm/sharedRuntime_sparc.cpp
>>>>>>>>    No comments.
>>>>>>>> 
>>>>>>>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp
>>>>>>>>    No comments.
>>>>>>>> 
>>>>>>>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp
>>>>>>>>    No comments.
>>>>>>>> 
>>>>>>>> I'm guessing that PPC has the same issue, but I'm presuming
>>>>>>>> that someone else (Vladimir?) will handle that?
>>>>>>> Yes, I was hoping that I could file a follow-up bug for the platforms I didn?t know how to fix.
>>>>>>> 
>>>>>>> Updated review: http://cr.openjdk.java.net/~sla/8041934/webrev.01/
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> /Staffan
>>>>>>> 
>>>>>>>> Dan
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 5/8/14 12:06 AM, Staffan Larsen wrote:
>>>>>>>>> All,
>>>>>>>>> 
>>>>>>>>> This is a fix for an assert in JVMTI that verifies that JVMTI?s internal notion of the number of frames on the stack is correct.
>>>>>>>>> 
>>>>>>>>> When running in -Xcomp mode and enable single-stepping (or method_entry/exit) we will revert all frames on the stack to be run by the interpreter. Only the interpreter can send single-step and method_entry/exit. However, if one of the frames is a native wrapper, that frame will not be reverted (presumably because we don't know how to do that). This will cause us to miss a method_exit event when that native frame is popped. This in turn will mess up the logic in JVMTI that keeps track of the number of frames currently on the stack (see JvmtiThreadState::_cur_stack_depth) and will trigger the assert.
>>>>>>>>> 
>>>>>>>>> The proposed solution is to include a method_exit event in the native wrapper frame if interpreted mode has been enabled. This needs updates to SharedRuntime::generate_native_wrapper() for all platforms.
>>>>>>>>> 
>>>>>>>>> Kudos to Rickard for helping me write the code.
>>>>>>>>> 
>>>>>>>>> webrev: http://cr.openjdk.java.net/~sla/8041934/webrev.00/
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041934
>>>>>>>>> 
>>>>>>>>> The fix has been verified by running the failing test in JPRT with -Xcomp.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> /Staffan
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140514/df1da46e/attachment-0001.html>

From vladimir.kozlov at oracle.com  Wed May 14 18:56:33 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 14 May 2014 11:56:33 -0700
Subject: Request for review: JDK-8032970: stack size check methods for
	WhiteBox API
In-Reply-To: <537399D5.5040807@Oracle.COM>
References: <52F0F609.3000108@oracle.com> <52F0FC77.709@oracle.com>
	<52F12B6B.1000303@oracle.com> <537399D5.5040807@Oracle.COM>
Message-ID: <5373BC61.4060700@oracle.com>

Thank you explanation, Kirill

WBStackSize.java: please, use more descriptive names for variables:

fss < tss * 0.9 || fss > tss

You may want to run WBStackSize with -Xint. With compiled code stack 
consumption is different. jtreg test could be run with -Xcomp by harness 
(during Nightly), please, test such configurations.

Thanks,
Vladimir

On 5/14/14 9:29 AM, Kirill Shirokov wrote:
> Thanks to all reviewers!
>
> Could I ask to reivew the fixed patch:
> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.03/
>
> Bug report:
> https://bugs.openjdk.java.net/browse/JDK-8032970
>
> The new functions will be used in the existing JSR292 tests -- we see a
> lot of failures due to StackOverflowError.
>
> Best regards,
> Kirill
>
> On 02/04/2014 10:03 PM, Vladimir Kozlov wrote:
>> Kirill,
>>
>> You should include link to the bug report and add more explanation
>> what this changes for. Will new functions be used in new or existing
>> jsr292 tests?
>>
>> test/testlibrary_tests directory is used for classes used by other
>> tests. I think you need to move new test WBStackSize.java into
>> test/runtime directory.
>>
>> Thanks,
>> Vladimir
>>
>> On 2/4/14 6:43 AM, Kirill Shirokov wrote:
>>> Hi,
>>>
>>> Please review following webrev, which adds stack size checking methods
>>> to WhiteBox API:
>>>
>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.00/
>>> <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.00/>
>>>
>>> Thank you,
>>> Kirill
>>>
>>>
>>>
>

From igor.veresov at oracle.com  Wed May 14 22:30:16 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 14 May 2014 15:30:16 -0700
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't
	enter safepoint
In-Reply-To: <7613371.caJJoI3tB6@mgerdin03>
References: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
	<6B76419A-328B-4D00-A8BF-FA9E5AEBD220@oracle.com>
	<1679027.HDHsSq8pUN@mgerdin03> <7613371.caJJoI3tB6@mgerdin03>
Message-ID: <99AC6EE8-932C-40FC-8834-4667DE25BF9B@oracle.com>

Hm, I always thought for some reason that we safepoint before taking the lock. Thanks for pointing this out!
I?ll have to think about this a bit. This particular lock if not a leaf one, so simply making it of a no_safepoint kind everywhere is problematic.

igor

On May 14, 2014, at 4:20 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:

> On Wednesday 14 May 2014 11.23.22 Mikael Gerdin wrote:
>> Igor,
>> 
>> On Wednesday 14 May 2014 01.35.46 Igor Veresov wrote:
>>> Would it be better if I assert that we don?t ever enter a safepoint in
>>> that
>>> scope? http://cr.openjdk.java.net/~iveresov/8043070/webrev.01/
>> 
>> Actually, I realized that Markus' bug is not the issue I thought it was.
>> What I meant was something similar to this bug which I fixed a while back:
>> https://bugs.openjdk.java.net/browse/JDK-8013129
>> 
>> Unfortunately I was scarce with details about the deadlock so I'm going to
>> backout the change and try to reproduce the deadlock to see the exact steps
>> it took to provoke it.
> 
> I managed to reproduce my earlier problem with mixing _no_safepoint_check_flag 
> on a single lock, here's how this can deadlock:
> 
> T1 is initiating a safepoint (for whatever reason)
> T2 is parked in Monitor::lock_without_safepoint_check -> Monitor::ILock
> T3 has returned from ILock in Monitor::lock and catches the safepoint in 
> ~ThreadBlockInVM
> 
> T2 will never reach the safepoint since it's blocking while _vm_running
> 
> I've updated https://bugs.openjdk.java.net/browse/JDK-8013129 with a stack 
> trace from a deadlocked VM.
> 
> /Mikael
> 
>> 
>> /Mikael
>> 
>>> igor
>>> 
>>> On May 14, 2014, at 12:39 AM, Igor Veresov <igor.veresov at oracle.com> 
> wrote:
>>>> Mikael,
>>>> 
>>>> I agree it?s ugly and we have to rethink the code management locks, but
>>>> it?s only dangerous if there is a safepoint-cooperating lock within the
>>>> scope of this one. There isn?t any, so I assume it should be safe.
>>>> Right?
>>>> 
>>>> igor
>>>> 
>>>> On May 14, 2014, at 12:04 AM, Mikael Gerdin <mikael.gerdin at oracle.com>
>> 
>> wrote:
>>>>> Igor,
>>>>> 
>>>>> On Tuesday 13 May 2014 18.11.48 Igor Veresov wrote:
>>>>>> nmethod::verify_interrupt_point() is called from as part of nmethod
>>>>>> verification from ciEnv::register_method() that asserts no safepoint
>>>>>> can
>>>>>> occur. However verify_interrupt_point() locks a mutex that may
>>>>>> potentially
>>>>>> safepoint. A sample call stack of when it happens is in the following
>>>>>> JBS
>>>>>> issue.
>>>>>> 
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070
>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/
>>>>> 
>>>>> It's unsafe to mix safepoint-aware and safepoint-ignoring locking on a
>>>>> single Mutex as that can deadlock the VM, see
>>>>> https://bugs.openjdk.java.net/browse/JDK-8039458
>>>>> 
>>>>> CompiledIC_lock is taken without _no_safepoint_check_flag at all other
>>>>> uses.
>>>>> 
>>>>> /Mikael
>>>>> 
>>>>>> igor
> 


From igor.veresov at oracle.com  Wed May 14 23:49:11 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 14 May 2014 16:49:11 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message 
Message-ID: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>

Forgot to name the deopt reason in the aging change. Also fixed some related LogCompilation printing.

Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/

Thanks,
igor

From christian.thalinger at oracle.com  Thu May 15 00:07:38 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 14 May 2014 17:07:38 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message
In-Reply-To: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>
Message-ID: <A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>

Can we add verification code to make sure this is the case?

const char* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
  // Note:  Keep this in sync. with enum DeoptReason.

And maybe this one too?

const char* Deoptimization::_trap_action_name[Action_LIMIT] = {
  // Note:  Keep this in sync. with enum DeoptAction.

On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com> wrote:

> Forgot to name the deopt reason in the aging change. Also fixed some related LogCompilation printing.
> 
> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
> 
> Thanks,
> igor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140514/37accc07/attachment.html>

From vladimir.kozlov at oracle.com  Thu May 15 00:26:03 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 14 May 2014 17:26:03 -0700
Subject: RFR (M) 8042786: Proper fix for 8032566
Message-ID: <5374099B.8060405@oracle.com>

http://cr.openjdk.java.net/~kvn/8042786/webrev/
https://bugs.openjdk.java.net/browse/JDK-8042786

8032566 was fixed in jdk8 by disabling autobox elimination: 
-XX:-EliminateAutoBox.

This fix will undo that change and fix the problem. In jdk9 8032566 
change was not applied before, I will push it first so that I could use 
the same 8042786 changeset for 8u backport.

The problem was that range check for loading from boxing cache was not 
eliminated but the load was removed when integer value is not in the 
cached range and it includes maxint: [256,maxint].

When autobox elimination is enabled the method IfNode::fold_compares() 
converts the value check in Integer.valueOf() to array range check and 
remove it as duplicate of the range check generated for the load:

     public static Integer valueOf(int i) {
         if (i >= IntegerCache.low && i <= IntegerCache.high)
             return IntegerCache.cache[i + (-IntegerCache.low)];
         return new Integer(i);
     }

The problem rise when result of AddI may overflow signed integer value. 
Let say the input value type range is [256, maxint]. Adding +128 will 
create 2 ranges due to overflow: [minint, minint+127] and [384, maxint]. 
But C2 type system keep only 1 type range and as result it use general 
[minint, maxint] for this case which we can't optimize.

On other hand ConvI2L::Ideal(), used in load's address expression, does 
transformation ConvI2L[-128,127](AddI(i, low)) to 
AddL(ConvI2L[0,255](i), low_long). ConvI2L is special node because it 
records the range type of related array access. In this case type range 
of ConvI2L is [-128,127] and after ideal transformation it is [0,255]. 
ConvI2L::Value() produces TOP after the transformation because int types 
[0,255] and [256,maxint] do not meet. And as result the load also 
eliminated.

We have a lot troubles with ConvI2L keeping a type which is valid only 
on some branch. The is RFE 6675699 to rework that (use CastII with 
control edge).

The suggested fix for this bug is to check for overflow cases in range 
checks and collapse it if we can. In CmpU::Value() we look in types of 
inputs of AddI node and check both type ranges when there is overflow.

I added code to put CmpU nodes on IGVN worklist if inputs of AddI were 
changed because AddI node may not be transformed (its type stays 
[minint, maxint] due to overflow).

Enabled IfNode::fold_compares() optimization for all cases.

Node notes were not constructed for new ideal nodes generated during 
post-parse inlining because C->default_node_notes() is set to NULL after 
Parse phase. Fix it by using root notes from the Call node we inline in 
do_late_inline().

The problem in customer case happened when boxing methods (valueOf) are 
inlined after Parse. Post-parse inlining may case other problems. I 
decided to do that only under experimental aggressive unboxing option 
and work on it more in 9.

I tested it with Scala build which showed the problem, ctw, jtreg, 
nashorn. I was not able to write a small test.

I tried to measure performance impact of the fix with nashorn running 
octane benchmarks. It was less than variations between runs.

Thanks,
Vladimir



From igor.veresov at oracle.com  Thu May 15 00:29:02 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 14 May 2014 17:29:02 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message 
In-Reply-To: <A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>
	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>
Message-ID: <EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>

Don?t quite know an easy way to that statically, but we can check at runtime:

http://cr.openjdk.java.net/~iveresov/8043180/webrev.01

igor

On May 14, 2014, at 5:07 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> Can we add verification code to make sure this is the case?
> 
> const char* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>   // Note:  Keep this in sync. with enum DeoptReason.
> 
> And maybe this one too?
> 
> const char* Deoptimization::_trap_action_name[Action_LIMIT] = {
>   // Note:  Keep this in sync. with enum DeoptAction.
> 
> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
>> Forgot to name the deopt reason in the aging change. Also fixed some related LogCompilation printing.
>> 
>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>> 
>> Thanks,
>> igor
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140514/48e6aab6/attachment-0001.html>

From vladimir.kozlov at oracle.com  Thu May 15 01:03:06 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 14 May 2014 18:03:06 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message
In-Reply-To: <EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>
	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
Message-ID: <5374124A.8090201@oracle.com>

Okay.

Vladimir

On 5/14/14 5:29 PM, Igor Veresov wrote:
> Don?t quite know an easy way to that statically, but we can check at
> runtime:
>
> http://cr.openjdk.java.net/~iveresov/8043180/webrev.01
>
> igor
>
> On May 14, 2014, at 5:07 PM, Christian Thalinger
> <christian.thalinger at oracle.com <mailto:christian.thalinger at oracle.com>>
> wrote:
>
>> Can we add verification code to make sure this is the case?
>>
>> constchar* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>> // Note:  Keep this in sync. with enum DeoptReason.
>>
>> And maybe this one too?
>>
>> constchar* Deoptimization::_trap_action_name[Action_LIMIT] = {
>> // Note:  Keep this in sync. with enum DeoptAction.
>>
>> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com
>> <mailto:igor.veresov at oracle.com>> wrote:
>>
>>> Forgot to name the deopt reason in the aging change. Also fixed some
>>> related LogCompilation printing.
>>>
>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>>>
>>> Thanks,
>>> igor
>>
>

From christian.thalinger at oracle.com  Thu May 15 01:05:25 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 14 May 2014 18:05:25 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message
In-Reply-To: <EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>
	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>
	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
Message-ID: <ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>

Yeah, something like this.  Better would be to check all entries in a verify method.  Also, can we be sure that undefined entries are initialized to zero on all platforms?

On May 14, 2014, at 5:29 PM, Igor Veresov <igor.veresov at oracle.com> wrote:

> Don?t quite know an easy way to that statically, but we can check at runtime:
> 
> http://cr.openjdk.java.net/~iveresov/8043180/webrev.01
> 
> igor
> 
> On May 14, 2014, at 5:07 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> Can we add verification code to make sure this is the case?
>> 
>> const char* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>>   // Note:  Keep this in sync. with enum DeoptReason.
>> 
>> And maybe this one too?
>> 
>> const char* Deoptimization::_trap_action_name[Action_LIMIT] = {
>>   // Note:  Keep this in sync. with enum DeoptAction.
>> 
>> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>> 
>>> Forgot to name the deopt reason in the aging change. Also fixed some related LogCompilation printing.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>>> 
>>> Thanks,
>>> igor
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140514/bed6cfba/attachment.html>

From vladimir.kozlov at oracle.com  Thu May 15 01:10:01 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 14 May 2014 18:10:01 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message
In-Reply-To: <ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
	<ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
Message-ID: <537413E9.3070506@oracle.com>

On 5/14/14 6:05 PM, Christian Thalinger wrote:
> Yeah, something like this.  Better would be to check all entries in a
> verify method.  Also, can we be sure that undefined entries are
> initialized to zero on all platforms?

According C++ spec, it should be NULL.

Vladimir

>
> On May 14, 2014, at 5:29 PM, Igor Veresov <igor.veresov at oracle.com
> <mailto:igor.veresov at oracle.com>> wrote:
>
>> Don?t quite know an easy way to that statically, but we can check at
>> runtime:
>>
>> http://cr.openjdk.java.net/~iveresov/8043180/webrev.01
>>
>> igor
>>
>> On May 14, 2014, at 5:07 PM, Christian Thalinger
>> <christian.thalinger at oracle.com
>> <mailto:christian.thalinger at oracle.com>> wrote:
>>
>>> Can we add verification code to make sure this is the case?
>>>
>>> constchar* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>>> // Note:  Keep this in sync. with enum DeoptReason.
>>>
>>> And maybe this one too?
>>>
>>> constchar* Deoptimization::_trap_action_name[Action_LIMIT] = {
>>> // Note:  Keep this in sync. with enum DeoptAction.
>>>
>>> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com
>>> <mailto:igor.veresov at oracle.com>> wrote:
>>>
>>>> Forgot to name the deopt reason in the aging change. Also fixed some
>>>> related LogCompilation printing.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>>>>
>>>> Thanks,
>>>> igor
>>>
>>
>

From john.r.rose at oracle.com  Thu May 15 01:26:16 2014
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 14 May 2014 18:26:16 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message 
In-Reply-To: <EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>
	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>
	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
Message-ID: <0A5C81A8-7FD5-4A9E-9C5A-543D19277A5C@oracle.com>

On May 14, 2014, at 5:29 PM, Igor Veresov <igor.veresov at oracle.com> wrote:

> Don?t quite know an easy way to that statically, but we can check at runtime:

Sometimes we use a spot-check, as in vmSymbols::initialize or the end of GraphKit::compute_stack_effects.

I suggest a line or two like:
   assert(0 == strcmp("constraint", trap_reason_name(Reason_constraint));
   const char* last_reason_name = "tenured";  // update this if enum DeoptReason changes
   assert(0 == strcmp(last_reason_name, trap_reason_name(Reason_LIMIT - 1));

...in some spot that gets executed at least once but not too often.

? John

From igor.veresov at oracle.com  Thu May 15 02:13:54 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 14 May 2014 19:13:54 -0700
Subject: RFR (M) 8042786: Proper fix for 8032566
In-Reply-To: <5374099B.8060405@oracle.com>
References: <5374099B.8060405@oracle.com>
Message-ID: <FA132DFF-A14A-4DBA-8FF6-3B3C06B78B2E@oracle.com>

Looks good.

igor

On May 14, 2014, at 5:26 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> http://cr.openjdk.java.net/~kvn/8042786/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8042786
> 
> 8032566 was fixed in jdk8 by disabling autobox elimination: -XX:-EliminateAutoBox.
> 
> This fix will undo that change and fix the problem. In jdk9 8032566 change was not applied before, I will push it first so that I could use the same 8042786 changeset for 8u backport.
> 
> The problem was that range check for loading from boxing cache was not eliminated but the load was removed when integer value is not in the cached range and it includes maxint: [256,maxint].
> 
> When autobox elimination is enabled the method IfNode::fold_compares() converts the value check in Integer.valueOf() to array range check and remove it as duplicate of the range check generated for the load:
> 
>    public static Integer valueOf(int i) {
>        if (i >= IntegerCache.low && i <= IntegerCache.high)
>            return IntegerCache.cache[i + (-IntegerCache.low)];
>        return new Integer(i);
>    }
> 
> The problem rise when result of AddI may overflow signed integer value. Let say the input value type range is [256, maxint]. Adding +128 will create 2 ranges due to overflow: [minint, minint+127] and [384, maxint]. But C2 type system keep only 1 type range and as result it use general [minint, maxint] for this case which we can't optimize.
> 
> On other hand ConvI2L::Ideal(), used in load's address expression, does transformation ConvI2L[-128,127](AddI(i, low)) to AddL(ConvI2L[0,255](i), low_long). ConvI2L is special node because it records the range type of related array access. In this case type range of ConvI2L is [-128,127] and after ideal transformation it is [0,255]. ConvI2L::Value() produces TOP after the transformation because int types [0,255] and [256,maxint] do not meet. And as result the load also eliminated.
> 
> We have a lot troubles with ConvI2L keeping a type which is valid only on some branch. The is RFE 6675699 to rework that (use CastII with control edge).
> 
> The suggested fix for this bug is to check for overflow cases in range checks and collapse it if we can. In CmpU::Value() we look in types of inputs of AddI node and check both type ranges when there is overflow.
> 
> I added code to put CmpU nodes on IGVN worklist if inputs of AddI were changed because AddI node may not be transformed (its type stays [minint, maxint] due to overflow).
> 
> Enabled IfNode::fold_compares() optimization for all cases.
> 
> Node notes were not constructed for new ideal nodes generated during post-parse inlining because C->default_node_notes() is set to NULL after Parse phase. Fix it by using root notes from the Call node we inline in do_late_inline().
> 
> The problem in customer case happened when boxing methods (valueOf) are inlined after Parse. Post-parse inlining may case other problems. I decided to do that only under experimental aggressive unboxing option and work on it more in 9.
> 
> I tested it with Scala build which showed the problem, ctw, jtreg, nashorn. I was not able to write a small test.
> 
> I tried to measure performance impact of the fix with nashorn running octane benchmarks. It was less than variations between runs.
> 
> Thanks,
> Vladimir
> 
> 


From john.r.rose at oracle.com  Thu May 15 02:14:34 2014
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 14 May 2014 19:14:34 -0700
Subject: RFR (M) 8042786: Proper fix for 8032566
In-Reply-To: <5374099B.8060405@oracle.com>
References: <5374099B.8060405@oracle.com>
Message-ID: <A1A5C7CF-6062-4D14-B830-B7F44BB93B63@oracle.com>

On May 14, 2014, at 5:26 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> http://cr.openjdk.java.net/~kvn/8042786/webrev/
> https://bugs.openjdk.java.net/browse/JDK-8042786
> 
> 8032566 was fixed in jdk8 by disabling autobox elimination: -XX:-EliminateAutoBox.
> 
> This fix will undo that change and fix the problem. In jdk9 8032566 change was not applied before, I will push it first so that I could use the same 8042786 changeset for 8u backport.

Nice change; reviewed.

One comment:  Surely there are better ways to differentiate the lower-case versions of the identifiers "HI1" and "HIL" by relying on "1" vs "l".
I suggest linking to prior "t1" as "t1_hi", "t1_lo".

This optimization might also be beneficial on some signed comparisons, notably (r1+r2)==0 where r1 and r2 are both [1..maxint].
So I suggest doing a follow-up application to CmpI.

? John

From vladimir.kozlov at oracle.com  Thu May 15 03:08:40 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 14 May 2014 20:08:40 -0700
Subject: RFR (M) 8042786: Proper fix for 8032566
In-Reply-To: <FA132DFF-A14A-4DBA-8FF6-3B3C06B78B2E@oracle.com>
References: <5374099B.8060405@oracle.com>
	<FA132DFF-A14A-4DBA-8FF6-3B3C06B78B2E@oracle.com>
Message-ID: <53742FB8.8090601@oracle.com>

Thank you, Igor

Vladimir

On 5/14/14 7:13 PM, Igor Veresov wrote:
> Looks good.
>
> igor
>
> On May 14, 2014, at 5:26 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> http://cr.openjdk.java.net/~kvn/8042786/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8042786
>>
>> 8032566 was fixed in jdk8 by disabling autobox elimination: -XX:-EliminateAutoBox.
>>
>> This fix will undo that change and fix the problem. In jdk9 8032566 change was not applied before, I will push it first so that I could use the same 8042786 changeset for 8u backport.
>>
>> The problem was that range check for loading from boxing cache was not eliminated but the load was removed when integer value is not in the cached range and it includes maxint: [256,maxint].
>>
>> When autobox elimination is enabled the method IfNode::fold_compares() converts the value check in Integer.valueOf() to array range check and remove it as duplicate of the range check generated for the load:
>>
>>     public static Integer valueOf(int i) {
>>         if (i >= IntegerCache.low && i <= IntegerCache.high)
>>             return IntegerCache.cache[i + (-IntegerCache.low)];
>>         return new Integer(i);
>>     }
>>
>> The problem rise when result of AddI may overflow signed integer value. Let say the input value type range is [256, maxint]. Adding +128 will create 2 ranges due to overflow: [minint, minint+127] and [384, maxint]. But C2 type system keep only 1 type range and as result it use general [minint, maxint] for this case which we can't optimize.
>>
>> On other hand ConvI2L::Ideal(), used in load's address expression, does transformation ConvI2L[-128,127](AddI(i, low)) to AddL(ConvI2L[0,255](i), low_long). ConvI2L is special node because it records the range type of related array access. In this case type range of ConvI2L is [-128,127] and after ideal transformation it is [0,255]. ConvI2L::Value() produces TOP after the transformation because int types [0,255] and [256,maxint] do not meet. And as result the load also eliminated.
>>
>> We have a lot troubles with ConvI2L keeping a type which is valid only on some branch. The is RFE 6675699 to rework that (use CastII with control edge).
>>
>> The suggested fix for this bug is to check for overflow cases in range checks and collapse it if we can. In CmpU::Value() we look in types of inputs of AddI node and check both type ranges when there is overflow.
>>
>> I added code to put CmpU nodes on IGVN worklist if inputs of AddI were changed because AddI node may not be transformed (its type stays [minint, maxint] due to overflow).
>>
>> Enabled IfNode::fold_compares() optimization for all cases.
>>
>> Node notes were not constructed for new ideal nodes generated during post-parse inlining because C->default_node_notes() is set to NULL after Parse phase. Fix it by using root notes from the Call node we inline in do_late_inline().
>>
>> The problem in customer case happened when boxing methods (valueOf) are inlined after Parse. Post-parse inlining may case other problems. I decided to do that only under experimental aggressive unboxing option and work on it more in 9.
>>
>> I tested it with Scala build which showed the problem, ctw, jtreg, nashorn. I was not able to write a small test.
>>
>> I tried to measure performance impact of the fix with nashorn running octane benchmarks. It was less than variations between runs.
>>
>> Thanks,
>> Vladimir
>>
>>
>

From igor.veresov at oracle.com  Thu May 15 05:01:38 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 14 May 2014 22:01:38 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message
In-Reply-To: <ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>
	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>
	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
	<ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
Message-ID: <881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>

I implemented a functionality mimicking static_assert in C++11 only to notice that we already have a STATIC_ASSERT in debug.hpp.
Anyways, here is the solution that asserts the proper array sizes statically.

Webrev:  http://cr.openjdk.java.net/~iveresov/8043180/webrev.02

igor

On May 14, 2014, at 6:05 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> Yeah, something like this.  Better would be to check all entries in a verify method.  Also, can we be sure that undefined entries are initialized to zero on all platforms?
> 
> On May 14, 2014, at 5:29 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
>> Don?t quite know an easy way to that statically, but we can check at runtime:
>> 
>> http://cr.openjdk.java.net/~iveresov/8043180/webrev.01
>> 
>> igor
>> 
>> On May 14, 2014, at 5:07 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> Can we add verification code to make sure this is the case?
>>> 
>>> const char* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>>>   // Note:  Keep this in sync. with enum DeoptReason.
>>> 
>>> And maybe this one too?
>>> 
>>> const char* Deoptimization::_trap_action_name[Action_LIMIT] = {
>>>   // Note:  Keep this in sync. with enum DeoptAction.
>>> 
>>> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>> 
>>>> Forgot to name the deopt reason in the aging change. Also fixed some related LogCompilation printing.
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>>>> 
>>>> Thanks,
>>>> igor
>>> 
>> 
> 


From vladimir.kozlov at oracle.com  Thu May 15 05:58:10 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 14 May 2014 22:58:10 -0700
Subject: RFR (M) 8042786: Proper fix for 8032566
In-Reply-To: <A1A5C7CF-6062-4D14-B830-B7F44BB93B63@oracle.com>
References: <5374099B.8060405@oracle.com>
	<A1A5C7CF-6062-4D14-B830-B7F44BB93B63@oracle.com>
Message-ID: <53745772.4020108@oracle.com>

Thank you, John

On 5/14/14 7:14 PM, John Rose wrote:
> On May 14, 2014, at 5:26 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> http://cr.openjdk.java.net/~kvn/8042786/webrev/
>> https://bugs.openjdk.java.net/browse/JDK-8042786
>>
>> 8032566 was fixed in jdk8 by disabling autobox elimination: -XX:-EliminateAutoBox.
>>
>> This fix will undo that change and fix the problem. In jdk9 8032566 change was not applied before, I will push it first so that I could use the same 8042786 changeset for 8u backport.
>
> Nice change; reviewed.
>
> One comment:  Surely there are better ways to differentiate the lower-case versions of the identifiers "HI1" and "HIL" by relying on "1" vs "l".
> I suggest linking to prior "t1" as "t1_hi", "t1_lo".

Okay. It is t11_lo and t12_lo.

>
> This optimization might also be beneficial on some signed comparisons, notably (r1+r2)==0 where r1 and r2 are both [1..maxint].
> So I suggest doing a follow-up application to CmpI.

Agree, I will file RFE.

About subtraction of [minint, x] which is converted into addition of [-x, -minint]. The concern was because -minint == 
minint in 32-bit int. I think it is fine in 64-bit long arithmetic which I used to detect overflow.

What I missed is the overlap check (hi_r1 < lo_r2) for new type ranges. If they overlap we back to [minint, maxint] 
bottom type and can't do optimization.

I will fix it and repeat testing tomorrow and will send new webrev.

>
> ? John
>

Thanks,
Vladimir

From vladimir.kozlov at oracle.com  Thu May 15 06:02:54 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 14 May 2014 23:02:54 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message
In-Reply-To: <881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>	<ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
	<881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
Message-ID: <5374588E.8030707@oracle.com>

Igor,

Why you placed STATIC_ASSERT inside methods? Can they be after arrays initialization code?

Thanks,
Vladimir

On 5/14/14 10:01 PM, Igor Veresov wrote:
> I implemented a functionality mimicking static_assert in C++11 only to notice that we already have a STATIC_ASSERT in debug.hpp.
> Anyways, here is the solution that asserts the proper array sizes statically.
>
> Webrev:  http://cr.openjdk.java.net/~iveresov/8043180/webrev.02
>
> igor
>
> On May 14, 2014, at 6:05 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>
>> Yeah, something like this.  Better would be to check all entries in a verify method.  Also, can we be sure that undefined entries are initialized to zero on all platforms?
>>
>> On May 14, 2014, at 5:29 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>
>>> Don?t quite know an easy way to that statically, but we can check at runtime:
>>>
>>> http://cr.openjdk.java.net/~iveresov/8043180/webrev.01
>>>
>>> igor
>>>
>>> On May 14, 2014, at 5:07 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>
>>>> Can we add verification code to make sure this is the case?
>>>>
>>>> const char* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>>>>    // Note:  Keep this in sync. with enum DeoptReason.
>>>>
>>>> And maybe this one too?
>>>>
>>>> const char* Deoptimization::_trap_action_name[Action_LIMIT] = {
>>>>    // Note:  Keep this in sync. with enum DeoptAction.
>>>>
>>>> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>>>
>>>>> Forgot to name the deopt reason in the aging change. Also fixed some related LogCompilation printing.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> igor
>>>>
>>>
>>
>

From igor.veresov at oracle.com  Thu May 15 06:29:46 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 14 May 2014 23:29:46 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message 
In-Reply-To: <5374588E.8030707@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>	<ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
	<881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
	<5374588E.8030707@oracle.com>
Message-ID: <D7C7A15A-704C-4634-8D3A-0D535F9BCF52@oracle.com>

It expands into a do-while loop. It needs to be in some function.

igor

On May 14, 2014, at 11:02 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Igor,
> 
> Why you placed STATIC_ASSERT inside methods? Can they be after arrays initialization code?
> 
> Thanks,
> Vladimir
> 
> On 5/14/14 10:01 PM, Igor Veresov wrote:
>> I implemented a functionality mimicking static_assert in C++11 only to notice that we already have a STATIC_ASSERT in debug.hpp.
>> Anyways, here is the solution that asserts the proper array sizes statically.
>> 
>> Webrev:  http://cr.openjdk.java.net/~iveresov/8043180/webrev.02
>> 
>> igor
>> 
>> On May 14, 2014, at 6:05 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> Yeah, something like this.  Better would be to check all entries in a verify method.  Also, can we be sure that undefined entries are initialized to zero on all platforms?
>>> 
>>> On May 14, 2014, at 5:29 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>> 
>>>> Don?t quite know an easy way to that statically, but we can check at runtime:
>>>> 
>>>> http://cr.openjdk.java.net/~iveresov/8043180/webrev.01
>>>> 
>>>> igor
>>>> 
>>>> On May 14, 2014, at 5:07 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>> 
>>>>> Can we add verification code to make sure this is the case?
>>>>> 
>>>>> const char* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>>>>>   // Note:  Keep this in sync. with enum DeoptReason.
>>>>> 
>>>>> And maybe this one too?
>>>>> 
>>>>> const char* Deoptimization::_trap_action_name[Action_LIMIT] = {
>>>>>   // Note:  Keep this in sync. with enum DeoptAction.
>>>>> 
>>>>> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>>>> 
>>>>>> Forgot to name the deopt reason in the aging change. Also fixed some related LogCompilation printing.
>>>>>> 
>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>>>>>> 
>>>>>> Thanks,
>>>>>> igor
>>>>> 
>>>> 
>>> 
>> 


From vladimir.kozlov at oracle.com  Thu May 15 07:26:53 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 15 May 2014 00:26:53 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message
In-Reply-To: <D7C7A15A-704C-4634-8D3A-0D535F9BCF52@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>	<ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
	<881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
	<5374588E.8030707@oracle.com>
	<D7C7A15A-704C-4634-8D3A-0D535F9BCF52@oracle.com>
Message-ID: <53746C3D.2090305@oracle.com>

I missed that. The fix looks good.

Thanks,
Vladimir

On 5/14/14 11:29 PM, Igor Veresov wrote:
> It expands into a do-while loop. It needs to be in some function.
>
> igor
>
> On May 14, 2014, at 11:02 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>
>> Igor,
>>
>> Why you placed STATIC_ASSERT inside methods? Can they be after arrays initialization code?
>>
>> Thanks,
>> Vladimir
>>
>> On 5/14/14 10:01 PM, Igor Veresov wrote:
>>> I implemented a functionality mimicking static_assert in C++11 only to notice that we already have a STATIC_ASSERT in debug.hpp.
>>> Anyways, here is the solution that asserts the proper array sizes statically.
>>>
>>> Webrev:  http://cr.openjdk.java.net/~iveresov/8043180/webrev.02
>>>
>>> igor
>>>
>>> On May 14, 2014, at 6:05 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>
>>>> Yeah, something like this.  Better would be to check all entries in a verify method.  Also, can we be sure that undefined entries are initialized to zero on all platforms?
>>>>
>>>> On May 14, 2014, at 5:29 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>>>
>>>>> Don?t quite know an easy way to that statically, but we can check at runtime:
>>>>>
>>>>> http://cr.openjdk.java.net/~iveresov/8043180/webrev.01
>>>>>
>>>>> igor
>>>>>
>>>>> On May 14, 2014, at 5:07 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>>>
>>>>>> Can we add verification code to make sure this is the case?
>>>>>>
>>>>>> const char* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>>>>>>    // Note:  Keep this in sync. with enum DeoptReason.
>>>>>>
>>>>>> And maybe this one too?
>>>>>>
>>>>>> const char* Deoptimization::_trap_action_name[Action_LIMIT] = {
>>>>>>    // Note:  Keep this in sync. with enum DeoptAction.
>>>>>>
>>>>>> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>>>>>
>>>>>>> Forgot to name the deopt reason in the aging change. Also fixed some related LogCompilation printing.
>>>>>>>
>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> igor
>>>>>>
>>>>>
>>>>
>>>
>

From igor.veresov at oracle.com  Thu May 15 07:39:13 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 15 May 2014 00:39:13 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message 
In-Reply-To: <53746C3D.2090305@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>	<ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
	<881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
	<5374588E.8030707@oracle.com>
	<D7C7A15A-704C-4634-8D3A-0D535F9BCF52@oracle.com>
	<53746C3D.2090305@oracle.com>
Message-ID: <23DDF6DA-E510-4BE7-9494-764D9EFA6F4B@oracle.com>

Thanks!

igor

On May 15, 2014, at 12:26 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> I missed that. The fix looks good.
> 
> Thanks,
> Vladimir
> 
> On 5/14/14 11:29 PM, Igor Veresov wrote:
>> It expands into a do-while loop. It needs to be in some function.
>> 
>> igor
>> 
>> On May 14, 2014, at 11:02 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>>> Igor,
>>> 
>>> Why you placed STATIC_ASSERT inside methods? Can they be after arrays initialization code?
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 5/14/14 10:01 PM, Igor Veresov wrote:
>>>> I implemented a functionality mimicking static_assert in C++11 only to notice that we already have a STATIC_ASSERT in debug.hpp.
>>>> Anyways, here is the solution that asserts the proper array sizes statically.
>>>> 
>>>> Webrev:  http://cr.openjdk.java.net/~iveresov/8043180/webrev.02
>>>> 
>>>> igor
>>>> 
>>>> On May 14, 2014, at 6:05 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>> 
>>>>> Yeah, something like this.  Better would be to check all entries in a verify method.  Also, can we be sure that undefined entries are initialized to zero on all platforms?
>>>>> 
>>>>> On May 14, 2014, at 5:29 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>>>> 
>>>>>> Don?t quite know an easy way to that statically, but we can check at runtime:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~iveresov/8043180/webrev.01
>>>>>> 
>>>>>> igor
>>>>>> 
>>>>>> On May 14, 2014, at 5:07 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>>>> 
>>>>>>> Can we add verification code to make sure this is the case?
>>>>>>> 
>>>>>>> const char* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>>>>>>>   // Note:  Keep this in sync. with enum DeoptReason.
>>>>>>> 
>>>>>>> And maybe this one too?
>>>>>>> 
>>>>>>> const char* Deoptimization::_trap_action_name[Action_LIMIT] = {
>>>>>>>   // Note:  Keep this in sync. with enum DeoptAction.
>>>>>>> 
>>>>>>> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>>>>>> 
>>>>>>>> Forgot to name the deopt reason in the aging change. Also fixed some related LogCompilation printing.
>>>>>>>> 
>>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> igor
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 


From tobias.hartmann at oracle.com  Thu May 15 12:44:49 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 15 May 2014 14:44:49 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed: init
	recursive calls: 51. After deopt 50"
Message-ID: <5374B6C1.5010903@oracle.com>

Hi,

please review the following patch for 8021775.

*Problem
*The compiler test for bug 8009761 checks if the stack size after 
deoptimization is the same as before by counting the number of possible 
recursive calls until a StackOverflowException occurs both before and 
after deoptimization. The test tries to trigger compilation by executing 
the method multiple times and enforces deoptimization by loading a 
previously unloaded class.

The test fails on multiple platforms.*
*Bug: https://bugs.openjdk.java.net/browse/JDK-8021775

*Solution**
*The test seems to be unstable, as there already occurred several test 
bugs (see 8010399 and 8012037). Enforcing compilation by executing a 
method multiple times is indeterministic. We have to make sure that the 
method is compiled and deoptimized exactly at those points in time where 
it is needed.

I reimplemented the test using the Whitebox API to deterministically 
trigger compilation and deoptimization.
Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
*
**Tests*
Executed test on machines where it previously failed (1k runs, no fails).

Thanks,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140515/a8ccc56f/attachment.html>

From roland.westrelin at oracle.com  Thu May 15 12:47:15 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 15 May 2014 14:47:15 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5374B6C1.5010903@oracle.com>
References: <5374B6C1.5010903@oracle.com>
Message-ID: <0B8543E3-B312-48F2-90C3-DB60A3063DE6@oracle.com>

Hi Tobias,

> Tests
> Executed test on machines where it previously failed (1k runs, no fails).

Did you get it to fail before you make the change (i.e. can you reproduce the failure)?

Roland.

From tobias.hartmann at oracle.com  Thu May 15 13:11:08 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 15 May 2014 15:11:08 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <0B8543E3-B312-48F2-90C3-DB60A3063DE6@oracle.com>
References: <5374B6C1.5010903@oracle.com>
	<0B8543E3-B312-48F2-90C3-DB60A3063DE6@oracle.com>
Message-ID: <5374BCEC.3000107@oracle.com>

Hi Roland,

On 15.05.2014 14:47, Roland Westrelin wrote:
> Hi Tobias,
>
>> Tests
>> Executed test on machines where it previously failed (1k runs, no fails).
> Did you get it to fail before you make the change (i.e. can you reproduce the failure)?

Yes, I reproduced it on spb23195 (see Daniels comment). With my changes 
it does not longer fail.

Thanks,
Tobias

>
> Roland.


From roland.westrelin at oracle.com  Thu May 15 13:15:07 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 15 May 2014 15:15:07 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5374BCEC.3000107@oracle.com>
References: <5374B6C1.5010903@oracle.com>
	<0B8543E3-B312-48F2-90C3-DB60A3063DE6@oracle.com>
	<5374BCEC.3000107@oracle.com>
Message-ID: <A92D8AA7-071A-4077-A52E-55C62F2382B1@oracle.com>

>>> Tests
>>> Executed test on machines where it previously failed (1k runs, no fails).
>> Did you get it to fail before you make the change (i.e. can you reproduce the failure)?
> 
> Yes, I reproduced it on spb23195 (see Daniels comment). With my changes it does not longer fail.

Can you explain what happens exactly so the test fails? 

Roland.

From tobias.hartmann at oracle.com  Thu May 15 13:26:00 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 15 May 2014 15:26:00 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <A92D8AA7-071A-4077-A52E-55C62F2382B1@oracle.com>
References: <5374B6C1.5010903@oracle.com>
	<0B8543E3-B312-48F2-90C3-DB60A3063DE6@oracle.com>
	<5374BCEC.3000107@oracle.com>
	<A92D8AA7-071A-4077-A52E-55C62F2382B1@oracle.com>
Message-ID: <5374C068.9010802@oracle.com>


>>>> Tests
>>>> Executed test on machines where it previously failed (1k runs, no fails).
>>> Did you get it to fail before you make the change (i.e. can you reproduce the failure)?
>> Yes, I reproduced it on spb23195 (see Daniels comment). With my changes it does not longer fail.
> Can you explain what happens exactly so the test fails?
>

Unfortunately I did not find out why it occurs. I was able to reliably 
reproduce it on this machine and it fails with "Failed: init recursive 
calls: 51. After deopt 50". But I think making the test more 
deterministic should at least help us fixing the problem if it turns out 
not to be a test bug.

Thanks,
Tobias

From christian.thalinger at oracle.com  Thu May 15 14:26:31 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 15 May 2014 07:26:31 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message
In-Reply-To: <881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>
	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>
	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
	<ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
	<881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
Message-ID: <40562DFE-26D1-433A-802D-B230313D596D@oracle.com>


On May 14, 2014, at 10:01 PM, Igor Veresov <igor.veresov at oracle.com> wrote:

> I implemented a functionality mimicking static_assert in C++11 only to notice that we already have a STATIC_ASSERT in debug.hpp.
> Anyways, here is the solution that asserts the proper array sizes statically.

Awesome.  Thanks.

> 
> Webrev:  http://cr.openjdk.java.net/~iveresov/8043180/webrev.02
> 
> igor
> 
> On May 14, 2014, at 6:05 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
>> Yeah, something like this.  Better would be to check all entries in a verify method.  Also, can we be sure that undefined entries are initialized to zero on all platforms?
>> 
>> On May 14, 2014, at 5:29 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>> 
>>> Don?t quite know an easy way to that statically, but we can check at runtime:
>>> 
>>> http://cr.openjdk.java.net/~iveresov/8043180/webrev.01
>>> 
>>> igor
>>> 
>>> On May 14, 2014, at 5:07 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>>> Can we add verification code to make sure this is the case?
>>>> 
>>>> const char* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>>>>  // Note:  Keep this in sync. with enum DeoptReason.
>>>> 
>>>> And maybe this one too?
>>>> 
>>>> const char* Deoptimization::_trap_action_name[Action_LIMIT] = {
>>>>  // Note:  Keep this in sync. with enum DeoptAction.
>>>> 
>>>> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>>> 
>>>>> Forgot to name the deopt reason in the aging change. Also fixed some related LogCompilation printing.
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>>>>> 
>>>>> Thanks,
>>>>> igor
>>>> 
>>> 
>> 
> 


From christian.thalinger at oracle.com  Thu May 15 14:31:43 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 15 May 2014 07:31:43 -0700
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5374B6C1.5010903@oracle.com>
References: <5374B6C1.5010903@oracle.com>
Message-ID: <63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>

Presumably:
+         WHITE_BOX.enqueueMethodForCompilation(m3, COMP_LEVEL_FULL_OPTIMIZATION);
+         if(!WHITE_BOX.isMethodCompiled(m3)) {
+             throw new RuntimeException(m3 + " not compiled");
          }
works because we?re using -XX:-BackgroundCompilation, correct?  Maybe add a comment there.  Can we verify via WB API that BackgroundCompilation is off?

I?m happy that using the WB API worked.

On May 15, 2014, at 5:44 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi,
> 
> please review the following patch for 8021775.
> 
> Problem
> The compiler test for bug 8009761 checks if the stack size after deoptimization is the same as before by counting the number of possible recursive calls until a StackOverflowException occurs both before and after deoptimization. The test tries to trigger compilation by executing the method multiple times and enforces deoptimization by loading a previously unloaded class. 
> 
> The test fails on multiple platforms.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8021775
> 
> Solution
> The test seems to be unstable, as there already occurred several test bugs (see 8010399 and 8012037). Enforcing compilation by executing a method multiple times is indeterministic. We have to make sure that the method is compiled and deoptimized exactly at those points in time where it is needed.
> 
> I reimplemented the test using the Whitebox API to deterministically trigger compilation and deoptimization.
> Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
> 
> Tests
> Executed test on machines where it previously failed (1k runs, no fails).
> 
> Thanks,
> Tobias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140515/303dcb8a/attachment.html>

From roland.westrelin at oracle.com  Thu May 15 14:53:14 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Thu, 15 May 2014 16:53:14 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5374C068.9010802@oracle.com>
References: <5374B6C1.5010903@oracle.com>
	<0B8543E3-B312-48F2-90C3-DB60A3063DE6@oracle.com>
	<5374BCEC.3000107@oracle.com>
	<A92D8AA7-071A-4077-A52E-55C62F2382B1@oracle.com>
	<5374C068.9010802@oracle.com>
Message-ID: <E73480C9-3078-4EC4-B1AB-E2950E37A6EB@oracle.com>

> Unfortunately I did not find out why it occurs. I was able to reliably reproduce it on this machine and it fails with "Failed: init recursive calls: 51. After deopt 50". But I think making the test more deterministic should at least help us fixing the problem if it turns out not to be a test bug.

I don?t understand what?s not deterministic if we use -BackgroundCompilation. So I?m concerned this will re-surfaced and is just hidden for some reason.

FWIW, I wrote the test which as you mention has been hard to make robust. I fixed a few issues with it and when I worked on them I think I remember noticing that the frame size after compilation + deoptimization could be slightly different from the initial interpreter frame size. And I assumed this was the cause of this bug (together with an unlucky stack alignment maybe) but never confirmed it. I think for this test it?s ok to allow the number of recursive calls to vary by +/- 1 before and after deoptimization. That?s the change I would have done.

Roland.

From igor.veresov at oracle.com  Thu May 15 17:33:41 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 15 May 2014 10:33:41 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message 
In-Reply-To: <40562DFE-26D1-433A-802D-B230313D596D@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>
	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>
	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
	<ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
	<881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
	<40562DFE-26D1-433A-802D-B230313D596D@oracle.com>
Message-ID: <49ABCD30-5AA6-41C7-A1FE-ABBA82974833@oracle.com>

Thanks!

igor

On May 15, 2014, at 7:26 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On May 14, 2014, at 10:01 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
>> I implemented a functionality mimicking static_assert in C++11 only to notice that we already have a STATIC_ASSERT in debug.hpp.
>> Anyways, here is the solution that asserts the proper array sizes statically.
> 
> Awesome.  Thanks.
> 
>> 
>> Webrev:  http://cr.openjdk.java.net/~iveresov/8043180/webrev.02
>> 
>> igor
>> 
>> On May 14, 2014, at 6:05 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> Yeah, something like this.  Better would be to check all entries in a verify method.  Also, can we be sure that undefined entries are initialized to zero on all platforms?
>>> 
>>> On May 14, 2014, at 5:29 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>> 
>>>> Don?t quite know an easy way to that statically, but we can check at runtime:
>>>> 
>>>> http://cr.openjdk.java.net/~iveresov/8043180/webrev.01
>>>> 
>>>> igor
>>>> 
>>>> On May 14, 2014, at 5:07 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>>> 
>>>>> Can we add verification code to make sure this is the case?
>>>>> 
>>>>> const char* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>>>>> // Note:  Keep this in sync. with enum DeoptReason.
>>>>> 
>>>>> And maybe this one too?
>>>>> 
>>>>> const char* Deoptimization::_trap_action_name[Action_LIMIT] = {
>>>>> // Note:  Keep this in sync. with enum DeoptAction.
>>>>> 
>>>>> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>>>> 
>>>>>> Forgot to name the deopt reason in the aging change. Also fixed some related LogCompilation printing.
>>>>>> 
>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>>>>>> 
>>>>>> Thanks,
>>>>>> igor
>>>>> 
>>>> 
>>> 
>> 
> 


From tobias.hartmann at oracle.com  Thu May 15 18:53:12 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 15 May 2014 20:53:12 +0200
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
Message-ID: <53750D18.6040201@oracle.com>

Hi,

please review the following patch that removes the IDX_INIT macro used 
by Node::Node(...) to retrieve the Compile object and replaces it by a 
call to Compile::current(). The Node constructor, new operator and all 
calls to it are adapted accordingly.

Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/

Tested with JPRT.

Thanks,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140515/b2458a34/attachment.html>

From igor.veresov at oracle.com  Thu May 15 19:05:18 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Thu, 15 May 2014 12:05:18 -0700
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <53750D18.6040201@oracle.com>
References: <53750D18.6040201@oracle.com>
Message-ID: <6A75FC89-F186-4AEF-9DE3-9805554135B0@oracle.com>

In ppc.ad you did s/new (C)//g instead of s/new (C)/new/g.
Otherwise seems alright.

igor

On May 15, 2014, at 11:53 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi,
> 
> please review the following patch that removes the IDX_INIT macro used by Node::Node(...) to retrieve the Compile object and replaces it by a call to Compile::current(). The Node constructor, new operator and all calls to it are adapted accordingly.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
> 
> Tested with JPRT.
> 
> Thanks,
> Tobias


From vladimir.kozlov at oracle.com  Thu May 15 20:57:41 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 15 May 2014 13:57:41 -0700
Subject: RFR (M) 8042786: Proper fix for 8032566
In-Reply-To: <53745772.4020108@oracle.com>
References: <5374099B.8060405@oracle.com>	<A1A5C7CF-6062-4D14-B830-B7F44BB93B63@oracle.com>
	<53745772.4020108@oracle.com>
Message-ID: <53752A45.3040303@oracle.com>

http://cr.openjdk.java.net/~kvn/8042786/webrev.01/

Only subnode.cpp was changed. Renamed variables and added missed overlap 
check (hi_tr1 < lo_tr2).

I thought more about subtraction of minint. I think the long arithmetic 
provides correct overflow answer for question about 2 type ranges. x 
-(-maxint) == x + maxint will overflow for x > 0. We should get the same 
overflow answer for x - minint because the subtraction result should be 
at the same range as x - (-maxint). And for negative x the answer should 
be 'no overflow'. Note, the numeric 32-bit result of x - minint is the 
same when executing int arithmetic or after casting long result to int. 
The difference only in overflow because in 32-bit -minint == minint.

Thanks,
Vladimir

On 5/14/14 10:58 PM, Vladimir Kozlov wrote:
> Thank you, John
>
> On 5/14/14 7:14 PM, John Rose wrote:
>> On May 14, 2014, at 5:26 PM, Vladimir Kozlov
>> <vladimir.kozlov at oracle.com> wrote:
>>
>>> http://cr.openjdk.java.net/~kvn/8042786/webrev/
>>> https://bugs.openjdk.java.net/browse/JDK-8042786
>>>
>>> 8032566 was fixed in jdk8 by disabling autobox elimination:
>>> -XX:-EliminateAutoBox.
>>>
>>> This fix will undo that change and fix the problem. In jdk9 8032566
>>> change was not applied before, I will push it first so that I could
>>> use the same 8042786 changeset for 8u backport.
>>
>> Nice change; reviewed.
>>
>> One comment:  Surely there are better ways to differentiate the
>> lower-case versions of the identifiers "HI1" and "HIL" by relying on
>> "1" vs "l".
>> I suggest linking to prior "t1" as "t1_hi", "t1_lo".
>
> Okay. It is t11_lo and t12_lo.
>
>>
>> This optimization might also be beneficial on some signed comparisons,
>> notably (r1+r2)==0 where r1 and r2 are both [1..maxint].
>> So I suggest doing a follow-up application to CmpI.
>
> Agree, I will file RFE.
>
> About subtraction of [minint, x] which is converted into addition of
> [-x, -minint]. The concern was because -minint == minint in 32-bit int.
> I think it is fine in 64-bit long arithmetic which I used to detect
> overflow.
>
> What I missed is the overlap check (hi_r1 < lo_r2) for new type ranges.
> If they overlap we back to [minint, maxint] bottom type and can't do
> optimization.
>
> I will fix it and repeat testing tomorrow and will send new webrev.
>
>>
>> ? John
>>
>
> Thanks,
> Vladimir

From coleen.phillimore at oracle.com  Thu May 15 21:22:49 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 15 May 2014 17:22:49 -0400
Subject: RFR(XXS): JDK-6883953 java -client -XX:ValueMapInitialSize=0
	crashes
In-Reply-To: <ABC6F6B1F6CA734A9B233369A3750F15235161@MBX021-W3-CA-4.exch021.domain.local>
References: <ABC6F6B1F6CA734A9B233369A3750F15235161@MBX021-W3-CA-4.exch021.domain.local>
Message-ID: <53753029.8070306@oracle.com>


Hi Yuri,
Since this is a compiler change, I'm including the compiler alias.
Coleen

On 5/15/14, 11:29 AM, Yuri Gaevsky wrote:
> Hello.
>
> I am looking for a sponsor to review and to integrate this simple fix into JDK 9:
>
> $ cat hotspot.patch
> --- old/src/share/vm/runtime/arguments.cpp      2014-05-15 18:43:52.907532800 +0400
> +++ new/src/share/vm/runtime/arguments.cpp      2014-05-15 18:43:52.595018700 +0400
> @@ -2335,6 +2335,7 @@
>     status = status && verify_percentage(MarkSweepDeadRatio, "MarkSweepDeadRatio");
>   
>     status = status && verify_min_value(MarkSweepAlwaysCompactCount, 1, "MarkSweepAlwaysCompactCount");
> +  status = status && verify_min_value(ValueMapInitialSize, 1, "ValueMapInitialSize");
>   
>     if (PrintNMTStatistics) {
>   #if INCLUDE_NMT
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6883953
> Summary: Limit ValueMapInitialSize minimal value by 1.
> Tests:  JCK-runtime-8 [api/[java_lang|java_util] & vm/] (Windows).
>
> Thank you,
> -Yuri
>


From vladimir.kozlov at oracle.com  Thu May 15 21:27:32 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 15 May 2014 14:27:32 -0700
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <53750D18.6040201@oracle.com>
References: <53750D18.6040201@oracle.com>
Message-ID: <53753144.5060707@oracle.com>

Tobias,

Changes are fine but I am concern about compilation speed.
Please, test compilation performance (-XX:+TimeCompiler) on x86 and 
sparc. You need to build optimized VM for that to exclude assert but 
keep statistic code. I would suggest to run one of nashorn octane 
benchmarks with -Xcomp -XX:-TieredCompilation to get compilation with 
big graphs.

Thanks,
Vladimir

On 5/15/14 11:53 AM, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch that removes the IDX_INIT macro used
> by Node::Node(...) to retrieve the Compile object and replaces it by a
> call to Compile::current(). The Node constructor, new operator and all
> calls to it are adapted accordingly.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
>
> Tested with JPRT.
>
> Thanks,
> Tobias

From john.r.rose at oracle.com  Thu May 15 21:50:13 2014
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 15 May 2014 14:50:13 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message
In-Reply-To: <881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>
	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>
	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
	<ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
	<881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
Message-ID: <648A4AC8-0C77-4E14-BF1B-A0C721EB4C76@oracle.com>

On May 14, 2014, at 10:01 PM, Igor Veresov <igor.veresov at oracle.com> wrote:

> I implemented a functionality mimicking static_assert in C++11 only to notice that we already have a STATIC_ASSERT in debug.hpp.
> Anyways, here is the solution that asserts the proper array sizes statically.
> 
> Webrev:  http://cr.openjdk.java.net/~iveresov/8043180/webrev.02

We also have ARRAY_SIZE (in globalDef's.hpp).  Might as well use that also.

(Yes, the name is a little feeble, but there it is.  I might have called it ARRAY_LENGTH or array_element_count.)

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140515/aabe2468/attachment.html>

From john.r.rose at oracle.com  Thu May 15 21:50:13 2014
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 15 May 2014 14:50:13 -0700
Subject: RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message
In-Reply-To: <881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
References: <F1402550-CF9A-4370-A24F-1DD1BF388ACA@oracle.com>
	<A440951D-8DAB-4C0E-B92C-7B92492DC8DC@oracle.com>
	<EF22C5F0-6CD7-4D96-8FB9-B810F59634EA@oracle.com>
	<ADF7DAFA-94CB-4AFD-A655-BBE5E25037E1@oracle.com>
	<881BDAA7-E28D-4FDD-9327-D04F5FA1097C@oracle.com>
Message-ID: <648A4AC8-0C77-4E14-BF1B-A0C721EB4C76@oracle.com>

On May 14, 2014, at 10:01 PM, Igor Veresov <igor.veresov at oracle.com> wrote:

> I implemented a functionality mimicking static_assert in C++11 only to notice that we already have a STATIC_ASSERT in debug.hpp.
> Anyways, here is the solution that asserts the proper array sizes statically.
> 
> Webrev:  http://cr.openjdk.java.net/~iveresov/8043180/webrev.02

We also have ARRAY_SIZE (in globalDef's.hpp).  Might as well use that also.

(Yes, the name is a little feeble, but there it is.  I might have called it ARRAY_LENGTH or array_element_count.)

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140515/aabe2468/attachment-0001.html>

From goetz.lindenmaier at sap.com  Fri May 16 08:01:23 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 16 May 2014 08:01:23 +0000
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <6A75FC89-F186-4AEF-9DE3-9805554135B0@oracle.com>
References: <53750D18.6040201@oracle.com>
	<6A75FC89-F186-4AEF-9DE3-9805554135B0@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEC352B@DEWDFEMB12A.global.corp.sap>

Hi Tobias,

thanks for editing ppc!  I'll test the change and also supply a fix
for the issue mentioned by Igor.  Is it ok if I just send a patch with 
the diffs?

Best regards,
  Geotz.

-----Original Message-----
From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Igor Veresov
Sent: Donnerstag, 15. Mai 2014 21:05
To: Tobias Hartmann
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class

In ppc.ad you did s/new (C)//g instead of s/new (C)/new/g.
Otherwise seems alright.

igor

On May 15, 2014, at 11:53 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi,
> 
> please review the following patch that removes the IDX_INIT macro used by Node::Node(...) to retrieve the Compile object and replaces it by a call to Compile::current(). The Node constructor, new operator and all calls to it are adapted accordingly.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
> 
> Tested with JPRT.
> 
> Thanks,
> Tobias


From tobias.hartmann at oracle.com  Fri May 16 08:28:57 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 16 May 2014 10:28:57 +0200
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEC352B@DEWDFEMB12A.global.corp.sap>
References: <53750D18.6040201@oracle.com>
	<6A75FC89-F186-4AEF-9DE3-9805554135B0@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEC352B@DEWDFEMB12A.global.corp.sap>
Message-ID: <5375CC49.5080107@oracle.com>

Vladimir, Goetz, thanks for the feedback.

On 16.05.2014 10:01, Lindenmaier, Goetz wrote:
> Hi Tobias,
>
> thanks for editing ppc!  I'll test the change and also supply a fix
> for the issue mentioned by Igor.  Is it ok if I just send a patch with
> the diffs?

I fixed it, please find the new webrev at
http://cr.openjdk.java.net/~anoll/8034812/webrev.01/

> Best regards,
>    Geotz.
>
> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Igor Veresov
> Sent: Donnerstag, 15. Mai 2014 21:05
> To: Tobias Hartmann
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
>
> In ppc.ad you did s/new (C)//g instead of s/new (C)/new/g.
> Otherwise seems alright.

Thank you! I wonder why this was not caught by JPRT.

Best,
Tobias

> igor
>
> On May 15, 2014, at 11:53 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>
>> Hi,
>>
>> please review the following patch that removes the IDX_INIT macro used by Node::Node(...) to retrieve the Compile object and replaces it by a call to Compile::current(). The Node constructor, new operator and all calls to it are adapted accordingly.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
>> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
>>
>> Tested with JPRT.
>>
>> Thanks,
>> Tobias


From volker.simonis at gmail.com  Fri May 16 08:41:25 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 16 May 2014 10:41:25 +0200
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <5375CC49.5080107@oracle.com>
References: <53750D18.6040201@oracle.com>
	<6A75FC89-F186-4AEF-9DE3-9805554135B0@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEC352B@DEWDFEMB12A.global.corp.sap>
	<5375CC49.5080107@oracle.com>
Message-ID: <CA+3eh132Medvfd1bKcg0y=maOW3U0St-J+AFdS8dn1p8Ud_WpQ@mail.gmail.com>

On Fri, May 16, 2014 at 10:28 AM, Tobias Hartmann
<tobias.hartmann at oracle.com> wrote:
> Vladimir, Goetz, thanks for the feedback.
>
>
> On 16.05.2014 10:01, Lindenmaier, Goetz wrote:
>>
>> Hi Tobias,
>>
>> thanks for editing ppc!  I'll test the change and also supply a fix
>> for the issue mentioned by Igor.  Is it ok if I just send a patch with
>> the diffs?
>
>
> I fixed it, please find the new webrev at
> http://cr.openjdk.java.net/~anoll/8034812/webrev.01/
>
>
>> Best regards,
>>    Geotz.
>>
>> -----Original Message-----
>> From: hotspot-compiler-dev
>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Igor
>> Veresov
>> Sent: Donnerstag, 15. Mai 2014 21:05
>> To: Tobias Hartmann
>> Cc: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
>>
>> In ppc.ad you did s/new (C)//g instead of s/new (C)/new/g.
>> Otherwise seems alright.
>
>
> Thank you! I wonder why this was not caught by JPRT.
>

Because JPRT doesn't build 64-bit PPC.

> Best,
> Tobias
>
>
>> igor
>>
>> On May 15, 2014, at 11:53 AM, Tobias Hartmann <tobias.hartmann at oracle.com>
>> wrote:
>>
>>> Hi,
>>>
>>> please review the following patch that removes the IDX_INIT macro used by
>>> Node::Node(...) to retrieve the Compile object and replaces it by a call to
>>> Compile::current(). The Node constructor, new operator and all calls to it
>>> are adapted accordingly.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
>>> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
>>>
>>> Tested with JPRT.
>>>
>>> Thanks,
>>> Tobias
>
>

From tobias.hartmann at oracle.com  Fri May 16 08:45:21 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 16 May 2014 10:45:21 +0200
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <CA+3eh132Medvfd1bKcg0y=maOW3U0St-J+AFdS8dn1p8Ud_WpQ@mail.gmail.com>
References: <53750D18.6040201@oracle.com>	<6A75FC89-F186-4AEF-9DE3-9805554135B0@oracle.com>	<4295855A5C1DE049A61835A1887419CC2CEC352B@DEWDFEMB12A.global.corp.sap>	<5375CC49.5080107@oracle.com>
	<CA+3eh132Medvfd1bKcg0y=maOW3U0St-J+AFdS8dn1p8Ud_WpQ@mail.gmail.com>
Message-ID: <5375D021.50808@oracle.com>


On 16.05.2014 10:41, Volker Simonis wrote:
> On Fri, May 16, 2014 at 10:28 AM, Tobias Hartmann
> <tobias.hartmann at oracle.com> wrote:
>> Vladimir, Goetz, thanks for the feedback.
>>
>>
>> On 16.05.2014 10:01, Lindenmaier, Goetz wrote:
>>> Hi Tobias,
>>>
>>> thanks for editing ppc!  I'll test the change and also supply a fix
>>> for the issue mentioned by Igor.  Is it ok if I just send a patch with
>>> the diffs?
>>
>> I fixed it, please find the new webrev at
>> http://cr.openjdk.java.net/~anoll/8034812/webrev.01/
>>
>>
>>> Best regards,
>>>     Geotz.
>>>
>>> -----Original Message-----
>>> From: hotspot-compiler-dev
>>> [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Igor
>>> Veresov
>>> Sent: Donnerstag, 15. Mai 2014 21:05
>>> To: Tobias Hartmann
>>> Cc: hotspot-compiler-dev at openjdk.java.net
>>> Subject: Re: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
>>>
>>> In ppc.ad you did s/new (C)//g instead of s/new (C)/new/g.
>>> Otherwise seems alright.
>>
>> Thank you! I wonder why this was not caught by JPRT.
>>
> Because JPRT doesn't build 64-bit PPC.

Okay, indeed.

Thanks,
Tobias

>
>> Best,
>> Tobias
>>
>>
>>> igor
>>>
>>> On May 15, 2014, at 11:53 AM, Tobias Hartmann <tobias.hartmann at oracle.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> please review the following patch that removes the IDX_INIT macro used by
>>>> Node::Node(...) to retrieve the Compile object and replaces it by a call to
>>>> Compile::current(). The Node constructor, new operator and all calls to it
>>>> are adapted accordingly.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
>>>> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
>>>>
>>>> Tested with JPRT.
>>>>
>>>> Thanks,
>>>> Tobias
>>


From goetz.lindenmaier at sap.com  Fri May 16 09:23:32 2014
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 16 May 2014 09:23:32 +0000
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <5375CC49.5080107@oracle.com>
References: <53750D18.6040201@oracle.com>
	<6A75FC89-F186-4AEF-9DE3-9805554135B0@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEC352B@DEWDFEMB12A.global.corp.sap>
	<5375CC49.5080107@oracle.com>
Message-ID: <4295855A5C1DE049A61835A1887419CC2CEC3586@DEWDFEMB12A.global.corp.sap>

Hi Tobias,

attached the patch for ppc.ad.  It worked fine except for what 
Igor detected.
The patch applies to the original ppc.ad version, not on top
of your change.

Tell me in case the patch was stripped by some mailing program, 
I assume this happens for the mailing list.

Best regards,
  Goetz.

-----Original Message-----
From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com] 
Sent: Freitag, 16. Mai 2014 10:29
To: Lindenmaier, Goetz; Igor Veresov
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class

Vladimir, Goetz, thanks for the feedback.

On 16.05.2014 10:01, Lindenmaier, Goetz wrote:
> Hi Tobias,
>
> thanks for editing ppc!  I'll test the change and also supply a fix
> for the issue mentioned by Igor.  Is it ok if I just send a patch with
> the diffs?

I fixed it, please find the new webrev at
http://cr.openjdk.java.net/~anoll/8034812/webrev.01/

> Best regards,
>    Geotz.
>
> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Igor Veresov
> Sent: Donnerstag, 15. Mai 2014 21:05
> To: Tobias Hartmann
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
>
> In ppc.ad you did s/new (C)//g instead of s/new (C)/new/g.
> Otherwise seems alright.

Thank you! I wonder why this was not caught by JPRT.

Best,
Tobias

> igor
>
> On May 15, 2014, at 11:53 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>
>> Hi,
>>
>> please review the following patch that removes the IDX_INIT macro used by Node::Node(...) to retrieve the Compile object and replaces it by a call to Compile::current(). The Node constructor, new operator and all calls to it are adapted accordingly.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
>> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
>>
>> Tested with JPRT.
>>
>> Thanks,
>> Tobias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ppc.ad.patch
Type: application/octet-stream
Size: 20631 bytes
Desc: ppc.ad.patch
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140516/f4d89847/ppc.ad-0001.patch>

From tobias.hartmann at oracle.com  Fri May 16 09:38:20 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 16 May 2014 11:38:20 +0200
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEC3586@DEWDFEMB12A.global.corp.sap>
References: <53750D18.6040201@oracle.com>
	<6A75FC89-F186-4AEF-9DE3-9805554135B0@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEC352B@DEWDFEMB12A.global.corp.sap>
	<5375CC49.5080107@oracle.com>
	<4295855A5C1DE049A61835A1887419CC2CEC3586@DEWDFEMB12A.global.corp.sap>
Message-ID: <5375DC8C.4030400@oracle.com>

Hi Goetz,

thank you! Looks like it is equal to my patch 
(http://cr.openjdk.java.net/~anoll/8034812/webrev.01/src/cpu/ppc/vm/ppc.ad.patch).

Best,
Tobias

On 16.05.2014 11:23, Lindenmaier, Goetz wrote:
> Hi Tobias,
>
> attached the patch for ppc.ad.  It worked fine except for what
> Igor detected.
> The patch applies to the original ppc.ad version, not on top
> of your change.
>
> Tell me in case the patch was stripped by some mailing program,
> I assume this happens for the mailing list.
>
> Best regards,
>    Goetz.
>
> -----Original Message-----
> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com]
> Sent: Freitag, 16. Mai 2014 10:29
> To: Lindenmaier, Goetz; Igor Veresov
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
>
> Vladimir, Goetz, thanks for the feedback.
>
> On 16.05.2014 10:01, Lindenmaier, Goetz wrote:
>> Hi Tobias,
>>
>> thanks for editing ppc!  I'll test the change and also supply a fix
>> for the issue mentioned by Igor.  Is it ok if I just send a patch with
>> the diffs?
> I fixed it, please find the new webrev at
> http://cr.openjdk.java.net/~anoll/8034812/webrev.01/
>
>> Best regards,
>>     Geotz.
>>
>> -----Original Message-----
>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Igor Veresov
>> Sent: Donnerstag, 15. Mai 2014 21:05
>> To: Tobias Hartmann
>> Cc: hotspot-compiler-dev at openjdk.java.net
>> Subject: Re: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
>>
>> In ppc.ad you did s/new (C)//g instead of s/new (C)/new/g.
>> Otherwise seems alright.
> Thank you! I wonder why this was not caught by JPRT.
>
> Best,
> Tobias
>
>> igor
>>
>> On May 15, 2014, at 11:53 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>>
>>> Hi,
>>>
>>> please review the following patch that removes the IDX_INIT macro used by Node::Node(...) to retrieve the Compile object and replaces it by a call to Compile::current(). The Node constructor, new operator and all calls to it are adapted accordingly.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
>>> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
>>>
>>> Tested with JPRT.
>>>
>>> Thanks,
>>> Tobias


From tobias.hartmann at oracle.com  Fri May 16 11:29:39 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 16 May 2014 13:29:39 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>
References: <5374B6C1.5010903@oracle.com>
	<63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>
Message-ID: <5375F6A3.3010307@oracle.com>

Hi Chris,

thanks for the review.

On 15.05.2014 16:31, Christian Thalinger wrote:
> Presumably:
> *+          WHITE_BOX.enqueueMethodForCompilation(m3, COMP_LEVEL_FULL_OPTIMIZATION);*
> *+          if(!WHITE_BOX.isMethodCompiled(m3)) {*
> *+             throw new RuntimeException(m3 + " not compiled");*
>            }
> works because we?re using -XX:-BackgroundCompilation, correct?  Maybe 
> add a comment there. 

Yes, exactly.

>  Can we verify via WB API that BackgroundCompilation is off?

Yes, this is for example done in CompilerWhiteBoxTest::getVMOption(...) 
to set BACKGROUND_COMPILATION. But I think because we explicitly disable 
background compilation in the test header it should not be possible to 
re-enable it, right?

Thanks,
Tobias

>
> I?m happy that using the WB API worked.
>
> On May 15, 2014, at 5:44 AM, Tobias Hartmann 
> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>
>> Hi,
>>
>> please review the following patch for 8021775.
>>
>> *Problem
>> *The compiler test for bug 8009761 checks if the stack size after 
>> deoptimization is the same as before by counting the number of 
>> possible recursive calls until a StackOverflowException occurs both 
>> before and after deoptimization. The test tries to trigger 
>> compilation by executing the method multiple times and enforces 
>> deoptimization by loading a previously unloaded class.
>>
>> The test fails on multiple platforms.*
>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8021775
>>
>> *Solution**
>> *The test seems to be unstable, as there already occurred several 
>> test bugs (see 8010399 and 8012037). Enforcing compilation by 
>> executing a method multiple times is indeterministic. We have to make 
>> sure that the method is compiled and deoptimized exactly at those 
>> points in time where it is needed.
>>
>> I reimplemented the test using the Whitebox API to deterministically 
>> trigger compilation and deoptimization.
>> Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
>> *
>> **Tests*
>> Executed test on machines where it previously failed (1k runs, no fails).
>>
>> Thanks,
>> Tobias
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140516/5db9bc12/attachment.html>

From tobias.hartmann at oracle.com  Fri May 16 11:42:24 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 16 May 2014 13:42:24 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <E73480C9-3078-4EC4-B1AB-E2950E37A6EB@oracle.com>
References: <5374B6C1.5010903@oracle.com>
	<0B8543E3-B312-48F2-90C3-DB60A3063DE6@oracle.com>
	<5374BCEC.3000107@oracle.com>
	<A92D8AA7-071A-4077-A52E-55C62F2382B1@oracle.com>
	<5374C068.9010802@oracle.com>
	<E73480C9-3078-4EC4-B1AB-E2950E37A6EB@oracle.com>
Message-ID: <5375F9A0.30106@oracle.com>

Hi Roland,

thanks for the review.

On 15.05.2014 16:53, Roland Westrelin wrote:
>> Unfortunately I did not find out why it occurs. I was able to reliably reproduce it on this machine and it fails with "Failed: init recursive calls: 51. After deopt 50". But I think making the test more deterministic should at least help us fixing the problem if it turns out not to be a test bug.
> I don?t understand what?s not deterministic if we use -BackgroundCompilation. So I?m concerned this will re-surfaced and is just hidden for some reason.

Yes, you are right. But I still think that by using the Whitebox API the 
intended behaviour is made more explicit in the test code.

> FWIW, I wrote the test which as you mention has been hard to make robust. I fixed a few issues with it and when I worked on them I think I remember noticing that the frame size after compilation + deoptimization could be slightly different from the initial interpreter frame size. And I assumed this was the cause of this bug (together with an unlucky stack alignment maybe) but never confirmed it. I think for this test it?s ok to allow the number of recursive calls to vary by +/- 1 before and after deoptimization. That?s the change I would have done.

Okay, I'm fine with changing the test to allow recursive calls to vary 
by 1. Should I then remove the usage of the Whitebox API?

Thanks,
Tobias

> Roland.


From roland.westrelin at oracle.com  Fri May 16 13:01:09 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 16 May 2014 15:01:09 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5375F9A0.30106@oracle.com>
References: <5374B6C1.5010903@oracle.com>
	<0B8543E3-B312-48F2-90C3-DB60A3063DE6@oracle.com>
	<5374BCEC.3000107@oracle.com>
	<A92D8AA7-071A-4077-A52E-55C62F2382B1@oracle.com>
	<5374C068.9010802@oracle.com>
	<E73480C9-3078-4EC4-B1AB-E2950E37A6EB@oracle.com>
	<5375F9A0.30106@oracle.com>
Message-ID: <50984C6A-06C5-46F9-97DC-B5E37DBEE5CF@oracle.com>

Hi Tobias,

> Okay, I'm fine with changing the test to allow recursive calls to vary by 1. Should I then remove the usage of the Whitebox API?

I?m ok with keeping the whitebox API. 

Roland.

From christian.thalinger at oracle.com  Fri May 16 15:57:11 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 16 May 2014 08:57:11 -0700
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <53753144.5060707@oracle.com>
References: <53750D18.6040201@oracle.com> <53753144.5060707@oracle.com>
Message-ID: <7796530B-AC96-49FC-8E03-524A8B422B6B@oracle.com>


On May 15, 2014, at 2:27 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Tobias,
> 
> Changes are fine but I am concern about compilation speed.
> Please, test compilation performance (-XX:+TimeCompiler) on x86 and sparc. You need to build optimized VM for that to exclude assert but keep statistic code. I would suggest to run one of nashorn octane benchmarks with -Xcomp -XX:-TieredCompilation to get compilation with big graphs.

Before I filed the bug I tested compilation speed on a SPARC T4 and couldn?t notice any performance difference.  Anyway, this is just one data point.  Tobias, please do test on other platforms and machines as well.

> 
> Thanks,
> Vladimir
> 
> On 5/15/14 11:53 AM, Tobias Hartmann wrote:
>> Hi,
>> 
>> please review the following patch that removes the IDX_INIT macro used
>> by Node::Node(...) to retrieve the Compile object and replaces it by a
>> call to Compile::current(). The Node constructor, new operator and all
>> calls to it are adapted accordingly.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
>> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
>> 
>> Tested with JPRT.
>> 
>> Thanks,
>> Tobias


From john.r.rose at oracle.com  Fri May 16 15:58:26 2014
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 16 May 2014 08:58:26 -0700
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <53753144.5060707@oracle.com>
References: <53750D18.6040201@oracle.com> <53753144.5060707@oracle.com>
Message-ID: <8DF2728D-EB95-4B77-B5BF-FD61351A7C20@oracle.com>

On May 15, 2014, at 2:27 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Changes are fine but I am concern about compilation speed.
> Please, test compilation performance (-XX:+TimeCompiler) on x86 and sparc. You need to build optimized VM for that to exclude assert but keep statistic code. I would suggest to run one of nashorn octane benchmarks with -Xcomp -XX:-TieredCompilation to get compilation with big graphs.

A little software archeology brings up some of the history behind the "new(N,C)" hack:


D 1.156 05/06/29 16:29:14 vkozlov 258 257
6219945: C2 virtual methods cleanup. Reduce calls Compile::current().
https://bugs.openjdk.java.net/browse/JDK-6219945

So it's been 9 years; do we still want to reduce calls to Compile::current()?  As a wild guess, it could cause a 1% regression in compile speed.

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140516/da794fb9/attachment-0001.html>

From christian.thalinger at oracle.com  Fri May 16 16:00:14 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 16 May 2014 09:00:14 -0700
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5375F6A3.3010307@oracle.com>
References: <5374B6C1.5010903@oracle.com>
	<63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>
	<5375F6A3.3010307@oracle.com>
Message-ID: <D200E44A-EFEB-4772-A1DA-1B3FA6637D87@oracle.com>


On May 16, 2014, at 4:29 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> Hi Chris,
> 
> thanks for the review.
> 
> On 15.05.2014 16:31, Christian Thalinger wrote:
>> Presumably:
>> +         WHITE_BOX.enqueueMethodForCompilation(m3, COMP_LEVEL_FULL_OPTIMIZATION);
>> +         if(!WHITE_BOX.isMethodCompiled(m3)) {
>> +             throw new RuntimeException(m3 + " not compiled");
>>           }
>> works because we?re using -XX:-BackgroundCompilation, correct?  Maybe add a comment there.
> 
> Yes, exactly.
> 
>>  Can we verify via WB API that BackgroundCompilation is off?
> 
> Yes, this is for example done in CompilerWhiteBoxTest::getVMOption(...) to set BACKGROUND_COMPILATION. But I think because we explicitly disable background compilation in the test header it should not be possible to re-enable it, right?

Correct but who knows what test cleanup might happen in the future.  Maybe someday someone decides that we shouldn?t run tests with -BackgroundCompilation.  This test is not easy to get right and had a couple of issues already.  I want it fool proof.

> 
> Thanks,
> Tobias
> 
>> 
>> I?m happy that using the WB API worked.
>> 
>> On May 15, 2014, at 5:44 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>> 
>>> Hi,
>>> 
>>> please review the following patch for 8021775.
>>> 
>>> Problem
>>> The compiler test for bug 8009761 checks if the stack size after deoptimization is the same as before by counting the number of possible recursive calls until a StackOverflowException occurs both before and after deoptimization. The test tries to trigger compilation by executing the method multiple times and enforces deoptimization by loading a previously unloaded class. 
>>> 
>>> The test fails on multiple platforms.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8021775
>>> 
>>> Solution
>>> The test seems to be unstable, as there already occurred several test bugs (see 8010399 and 8012037). Enforcing compilation by executing a method multiple times is indeterministic. We have to make sure that the method is compiled and deoptimized exactly at those points in time where it is needed.
>>> 
>>> I reimplemented the test using the Whitebox API to deterministically trigger compilation and deoptimization.
>>> Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
>>> 
>>> Tests
>>> Executed test on machines where it previously failed (1k runs, no fails).
>>> 
>>> Thanks,
>>> Tobias
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140516/46c842c4/attachment.html>

From john.r.rose at oracle.com  Fri May 16 16:07:37 2014
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 16 May 2014 09:07:37 -0700
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <8DF2728D-EB95-4B77-B5BF-FD61351A7C20@oracle.com>
References: <53750D18.6040201@oracle.com> <53753144.5060707@oracle.com>
	<8DF2728D-EB95-4B77-B5BF-FD61351A7C20@oracle.com>
Message-ID: <9E16205E-3633-4F0D-B1CB-63BACC66680A@oracle.com>

On May 16, 2014, at 8:58 AM, John Rose <john.r.rose at oracle.com> wrote:

> On May 15, 2014, at 2:27 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
>> Changes are fine but I am concern about compilation speed.
>> Please, test compilation performance (-XX:+TimeCompiler) on x86 and sparc. You need to build optimized VM for that to exclude assert but keep statistic code. I would suggest to run one of nashorn octane benchmarks with -Xcomp -XX:-TieredCompilation to get compilation with big graphs.
> 
> A little software archeology brings up some of the history behind the "new(N,C)" hack:
> 
> 
D 1.156 05/06/29 16:29:14 vkozlov 258 257
> 6219945: C2 virtual methods cleanup. Reduce calls Compile::current().
> https://bugs.openjdk.java.net/browse/JDK-6219945
> 
> So it's been 9 years; do we still want to reduce calls to Compile::current()?  As a wild guess, it could cause a 1% regression in compile speed.
> 
> ? John

P.S. The IDX_INIT trick comes from this delta:
D 1.212 05/12/01 13:25:41 jrose 374 372
6175499 Stick contextual annotations onto newly-created nodes.

(Also, remove a frequent call to Compile::current().)
https://bugs.openjdk.java.net/browse/JDK-6175499

The "frequent call" was in the Node::Node constructors:


<<<
Node::Node( Node *n0 )
  : _out(NO_OUT_ARRAY),
    _cnt(1),
    _max(1),
    _outcnt(0),
    _outmax(0),
    _idx( Compile::current()->next_unique() ),
    _class_id(Class_Node),
    _flags(0) {

***
Node::Node(Node *n0)
  : _idx(IDX_INIT(1))
{

>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140516/68cbb6b0/attachment.html>

From vladimir.kozlov at oracle.com  Fri May 16 17:59:00 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 16 May 2014 10:59:00 -0700
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <9E16205E-3633-4F0D-B1CB-63BACC66680A@oracle.com>
References: <53750D18.6040201@oracle.com> <53753144.5060707@oracle.com>
	<8DF2728D-EB95-4B77-B5BF-FD61351A7C20@oracle.com>
	<9E16205E-3633-4F0D-B1CB-63BACC66680A@oracle.com>
Message-ID: <537651E4.6070108@oracle.com>

6219945 1% speedup was mostly due to replacing virtual methods with Node's new fields checks (_class_id, _flags).

We still need to avoid excessive Compile::current() usage because it has big call stack to get value. I agreed to 
current clean up after Christian showed no compilation performance difference on sparc.

Vladimir

On 5/16/14 9:07 AM, John Rose wrote:
> On May 16, 2014, at 8:58 AM, John Rose <john.r.rose at oracle.com <mailto:john.r.rose at oracle.com>> wrote:
>
>> On May 15, 2014, at 2:27 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>
>>> Changes are fine but I am concern about compilation speed.
>>> Please, test compilation performance (-XX:+TimeCompiler) on x86 and sparc. You need to build optimized VM for that to
>>> exclude assert but keep statistic code. I would suggest to run one of nashorn octane benchmarks with -Xcomp
>>> -XX:-TieredCompilation to get compilation with big graphs.
>>
>> A little software archeology brings up some of the history behind the "new(N,C)" hack:
>>
>> 
D 1.156 05/06/29 16:29:14 vkozlov 258 257
>> 6219945: C2 virtual methods cleanup. Reduce calls Compile::current().
>> https://bugs.openjdk.java.net/browse/JDK-6219945
>>
>> So it's been 9 years; do we still want to reduce calls to Compile::current()?  As a wild guess, it could cause a 1%
>> regression in compile speed.
>>
>> ? John
>
> P.S. The IDX_INIT trick comes from this delta:
> D 1.212 05/12/01 13:25:41 jrose 374 372
> 6175499 Stick contextual annotations onto newly-created nodes.
> 
(Also, remove a frequent call to Compile::current().)
> https://bugs.openjdk.java.net/browse/JDK-6175499
>
> The "frequent call" was in the Node::Node constructors:
>
> 
<<<
> Node::Node( Node *n0 )
>    : _out(NO_OUT_ARRAY),
>      _cnt(1),
>      _max(1),
>      _outcnt(0),
>      _outmax(0),
>      _idx( Compile::current()->next_unique() ),
>      _class_id(Class_Node),
>      _flags(0) {
> 
***
> Node::Node(Node *n0)
>    : _idx(IDX_INIT(1))
> {
> 
>>>
>

From mtraverso at gmail.com  Fri May 16 19:39:12 2014
From: mtraverso at gmail.com (Martin Traverso)
Date: Fri, 16 May 2014 12:39:12 -0700
Subject: segfault with 8u5
Message-ID: <CAEBmgdrQi-B_y+UERkx6eVK6F-rSV=n-7mXwAVoAcV+vGm4rvQ@mail.gmail.com>

We're testing Presto (https://github.com/facebook/presto) on Java 8, and
ran into a segfault in the VM. Below is the relevant portion from the crash
report. You can see the full dump here:
https://gist.github.com/martint/364a12d4f776a6e54911

Stack: [0x00007fe8a1a6c000,0x00007fe8a1b6d000],
sp=0x00007fe8a1b6abe0,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x3fd2f8]  ciSignature::ciSignature(ciKlass*, ciSymbol*,
ciMethodType*)+0x178
V  [libjvm.so+0x403ba7]  ciBytecodeStream::get_method(bool&,
ciSignature**)+0x4a7
V  [libjvm.so+0x332099]  GraphBuilder::invoke(Bytecodes::Code)+0x39
V  [libjvm.so+0x333b3d]  GraphBuilder::iterate_bytecodes_for_block(int)+0x6ad
V  [libjvm.so+0x330fa2]  GraphBuilder::iterate_all_blocks(bool)+0xf2
V  [libjvm.so+0x335a97]  GraphBuilder::GraphBuilder(Compilation*,
IRScope*)+0x517
V  [libjvm.so+0x33e337]  IRScope::IRScope(Compilation*, IRScope*, int,
ciMethod*, int, bool)+0x1e7
V  [libjvm.so+0x33e44f]  IR::IR(Compilation*, ciMethod*, int)+0x9f
V  [libjvm.so+0x31d74b]  Compilation::build_hir()+0xdb
V  [libjvm.so+0x31db0e]  Compilation::compile_java_method()+0x6e
V  [libjvm.so+0x31dc3e]  Compilation::compile_method()+0x4e
V  [libjvm.so+0x31df9f]  Compilation::Compilation(AbstractCompiler*,
ciEnv*, ciMethod*, int, BufferBlob*)+0x24f
V  [libjvm.so+0x31ed39]  Compiler::compile_method(ciEnv*, ciMethod*, int)+0xa9
V  [libjvm.so+0x46982a]
CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc8a
V  [libjvm.so+0x46c230]  CompileBroker::compiler_thread_loop()+0x620
V  [libjvm.so+0x9e303f]  JavaThread::thread_main_inner()+0xdf
V  [libjvm.so+0x9e3205]  JavaThread::run()+0x1b5
V  [libjvm.so+0x8a00c8]  java_start(Thread*)+0x108


Is this a known issue? I couldn't find anything related in the bug
database. Otherwise, any suggestions for debugging it would be very much
appreciated!
The problem only seems to happen after Presto has been running for a while
and has processed several hundred queries. I?ve tried re-running the
queries that were running at the moment it crashed, but it does not
reproduce deterministically. Also, we don't see it in Java 7.

Thanks!

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140516/5d96eaf8/attachment-0001.html>

From vladimir.kozlov at oracle.com  Fri May 16 21:37:56 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 16 May 2014 14:37:56 -0700
Subject: segfault with 8u5
In-Reply-To: <CAEBmgdrQi-B_y+UERkx6eVK6F-rSV=n-7mXwAVoAcV+vGm4rvQ@mail.gmail.com>
References: <CAEBmgdrQi-B_y+UERkx6eVK6F-rSV=n-7mXwAVoAcV+vGm4rvQ@mail.gmail.com>
Message-ID: <53768534.7050601@oracle.com>

The failure happened in C1 JIT compiler (first tier). You can try to 
switch off -XX:-TieredCompilation.



The failure happens in next line in inlined ptype_slot_count():

   _size( method_type->ptype_slot_count()),

   int ptype_slot_count() const {
     GUARDED_VM_ENTRY(return 
java_lang_invoke_MethodType::ptype_slot_count(get_oop());)
   }

0x00007f59aa5bc5b0: ciSignature+0x0170:	movq 
0xffffffffffffffc8(%rbp),%rdx
0x00007f59aa5bc5b4: ciSignature+0x0174:	movq 
0x0000000000000010(%rdx),%rax
0x00007f59aa5bc5b8: ciSignature+0x0178:	movq     (%rax),%rdi
0x00007f59aa5bc5bb: ciSignature+0x017b:	call     ptype_slot_count	[ 
0x7f59aa7f4320, .+0x237d65 ]

RAX=0x0000000000000000

Looks like method_type->_handle returned by get_oop() is NULL.

The only bug I found which could be related is next:

https://bugs.openjdk.java.net/browse/JDK-8029381

Regards,
Vladimir


On 5/16/14 12:39 PM, Martin Traverso wrote:
> We're testing Presto (https://github.com/facebook/presto) on Java 8, and
> ran into a segfault in the VM. Below is the relevant portion from the
> crash report. You can see the full dump here:
> https://gist.github.com/martint/364a12d4f776a6e54911
>
> Stack: [0x00007fe8a1a6c000,0x00007fe8a1b6d000], sp=0x00007fe8a1b6abe0,
> free space=1018k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> V [libjvm.so+0x3fd2f8] ciSignature::ciSignature(ciKlass*, ciSymbol*,
> ciMethodType*)+0x178
> V [libjvm.so+0x403ba7] ciBytecodeStream::get_method(bool&,
> ciSignature**)+0x4a7
>
> V [libjvm.so+0x332099] GraphBuilder::invoke(Bytecodes::Code)+0x39
> V [libjvm.so+0x333b3d] GraphBuilder::iterate_bytecodes_for_block(int)+0x6ad
>
> V [libjvm.so+0x330fa2] GraphBuilder::iterate_all_blocks(bool)+0xf2
> V [libjvm.so+0x335a97] GraphBuilder::GraphBuilder(Compilation*,
> IRScope*)+0x517
>
> V [libjvm.so+0x33e337] IRScope::IRScope(Compilation*, IRScope*, int,
> ciMethod*, int, bool)+0x1e7
> V [libjvm.so+0x33e44f] IR::IR(Compilation*, ciMethod*, int)+0x9f
>
> V [libjvm.so+0x31d74b] Compilation::build_hir()+0xdb
> V [libjvm.so+0x31db0e] Compilation::compile_java_method()+0x6e
> V [libjvm.so+0x31dc3e] Compilation::compile_method()+0x4e
> V [libjvm.so+0x31df9f] Compilation::Compilation(AbstractCompiler*,
> ciEnv*, ciMethod*, int, BufferBlob*)+0x24f
>
> V [libjvm.so+0x31ed39] Compiler::compile_method(ciEnv*, ciMethod*, int)+0xa9
> V [libjvm.so+0x46982a]
> CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc8a
>
> V [libjvm.so+0x46c230] CompileBroker::compiler_thread_loop()+0x620
> V [libjvm.so+0x9e303f] JavaThread::thread_main_inner()+0xdf
>
> V [libjvm.so+0x9e3205] JavaThread::run()+0x1b5
> V [libjvm.so+0x8a00c8] java_start(Thread*)+0x108
>
>
> Is this a known issue? I couldn't find anything related in the bug
> database. Otherwise, any suggestions for debugging it would be very much
> appreciated!
>
> The problem only seems to happen after Presto has been running for a
> while and has processed several hundred queries. I?ve tried re-running
> the queries that were running at the moment it crashed, but it does not
> reproduce deterministically. Also, we don't see it in Java 7.
>
> Thanks!
>
> Martin
>
>
>

From vladimir.kozlov at oracle.com  Fri May 16 21:52:53 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 16 May 2014 14:52:53 -0700
Subject: RFR(XXS): JDK-6883953 java -client -XX:ValueMapInitialSize=0
	crashes
In-Reply-To: <53753029.8070306@oracle.com>
References: <ABC6F6B1F6CA734A9B233369A3750F15235161@MBX021-W3-CA-4.exch021.domain.local>
	<53753029.8070306@oracle.com>
Message-ID: <537688B5.2010507@oracle.com>

Looks fine. I asked Niclas to sponsor this.

Thanks,
Vladimir

On 5/15/14 2:22 PM, Coleen Phillimore wrote:
>
> Hi Yuri,
> Since this is a compiler change, I'm including the compiler alias.
> Coleen
>
> On 5/15/14, 11:29 AM, Yuri Gaevsky wrote:
>> Hello.
>>
>> I am looking for a sponsor to review and to integrate this simple fix
>> into JDK 9:
>>
>> $ cat hotspot.patch
>> --- old/src/share/vm/runtime/arguments.cpp      2014-05-15
>> 18:43:52.907532800 +0400
>> +++ new/src/share/vm/runtime/arguments.cpp      2014-05-15
>> 18:43:52.595018700 +0400
>> @@ -2335,6 +2335,7 @@
>>     status = status && verify_percentage(MarkSweepDeadRatio,
>> "MarkSweepDeadRatio");
>>     status = status && verify_min_value(MarkSweepAlwaysCompactCount,
>> 1, "MarkSweepAlwaysCompactCount");
>> +  status = status && verify_min_value(ValueMapInitialSize, 1,
>> "ValueMapInitialSize");
>>     if (PrintNMTStatistics) {
>>   #if INCLUDE_NMT
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6883953
>> Summary: Limit ValueMapInitialSize minimal value by 1.
>> Tests:  JCK-runtime-8 [api/[java_lang|java_util] & vm/] (Windows).
>>
>> Thank you,
>> -Yuri
>>
>

From igor.veresov at oracle.com  Fri May 16 21:59:04 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Fri, 16 May 2014 14:59:04 -0700
Subject: segfault with 8u5
In-Reply-To: <53768534.7050601@oracle.com>
References: <CAEBmgdrQi-B_y+UERkx6eVK6F-rSV=n-7mXwAVoAcV+vGm4rvQ@mail.gmail.com>
	<53768534.7050601@oracle.com>
Message-ID: <EDD6D4A9-2E03-4ECA-8FC5-884178CDC4A5@oracle.com>

It also just deopted with Reason_uninitialized, I wonder if it?s the same call site.

Event: 11862.911 Thread 0x00007fe9567ca800 Uncommon trap: reason=uninitialized action=reinterpret pc=0x00007fe95073dab0 method=ScanFilterAndProjectOperator_699.project_0(Lcom/facebook/presto/spi/RecordCursor;Lcom/facebook/presto/spi/block/BlockBuilder;)V @ 166

igor


On May 16, 2014, at 2:37 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> The failure happened in C1 JIT compiler (first tier). You can try to switch off -XX:-TieredCompilation.
> 
> 
> 
> The failure happens in next line in inlined ptype_slot_count():
> 
>  _size( method_type->ptype_slot_count()),
> 
>  int ptype_slot_count() const {
>    GUARDED_VM_ENTRY(return java_lang_invoke_MethodType::ptype_slot_count(get_oop());)
>  }
> 
> 0x00007f59aa5bc5b0: ciSignature+0x0170:	movq 0xffffffffffffffc8(%rbp),%rdx
> 0x00007f59aa5bc5b4: ciSignature+0x0174:	movq 0x0000000000000010(%rdx),%rax
> 0x00007f59aa5bc5b8: ciSignature+0x0178:	movq     (%rax),%rdi
> 0x00007f59aa5bc5bb: ciSignature+0x017b:	call     ptype_slot_count	[ 0x7f59aa7f4320, .+0x237d65 ]
> 
> RAX=0x0000000000000000
> 
> Looks like method_type->_handle returned by get_oop() is NULL.
> 
> The only bug I found which could be related is next:
> 
> https://bugs.openjdk.java.net/browse/JDK-8029381
> 
> Regards,
> Vladimir
> 
> 
> On 5/16/14 12:39 PM, Martin Traverso wrote:
>> We're testing Presto (https://github.com/facebook/presto) on Java 8, and
>> ran into a segfault in the VM. Below is the relevant portion from the
>> crash report. You can see the full dump here:
>> https://gist.github.com/martint/364a12d4f776a6e54911
>> 
>> Stack: [0x00007fe8a1a6c000,0x00007fe8a1b6d000], sp=0x00007fe8a1b6abe0,
>> free space=1018k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>> C=native code)
>> V [libjvm.so+0x3fd2f8] ciSignature::ciSignature(ciKlass*, ciSymbol*,
>> ciMethodType*)+0x178
>> V [libjvm.so+0x403ba7] ciBytecodeStream::get_method(bool&,
>> ciSignature**)+0x4a7
>> 
>> V [libjvm.so+0x332099] GraphBuilder::invoke(Bytecodes::Code)+0x39
>> V [libjvm.so+0x333b3d] GraphBuilder::iterate_bytecodes_for_block(int)+0x6ad
>> 
>> V [libjvm.so+0x330fa2] GraphBuilder::iterate_all_blocks(bool)+0xf2
>> V [libjvm.so+0x335a97] GraphBuilder::GraphBuilder(Compilation*,
>> IRScope*)+0x517
>> 
>> V [libjvm.so+0x33e337] IRScope::IRScope(Compilation*, IRScope*, int,
>> ciMethod*, int, bool)+0x1e7
>> V [libjvm.so+0x33e44f] IR::IR(Compilation*, ciMethod*, int)+0x9f
>> 
>> V [libjvm.so+0x31d74b] Compilation::build_hir()+0xdb
>> V [libjvm.so+0x31db0e] Compilation::compile_java_method()+0x6e
>> V [libjvm.so+0x31dc3e] Compilation::compile_method()+0x4e
>> V [libjvm.so+0x31df9f] Compilation::Compilation(AbstractCompiler*,
>> ciEnv*, ciMethod*, int, BufferBlob*)+0x24f
>> 
>> V [libjvm.so+0x31ed39] Compiler::compile_method(ciEnv*, ciMethod*, int)+0xa9
>> V [libjvm.so+0x46982a]
>> CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc8a
>> 
>> V [libjvm.so+0x46c230] CompileBroker::compiler_thread_loop()+0x620
>> V [libjvm.so+0x9e303f] JavaThread::thread_main_inner()+0xdf
>> 
>> V [libjvm.so+0x9e3205] JavaThread::run()+0x1b5
>> V [libjvm.so+0x8a00c8] java_start(Thread*)+0x108
>> 
>> 
>> Is this a known issue? I couldn't find anything related in the bug
>> database. Otherwise, any suggestions for debugging it would be very much
>> appreciated!
>> 
>> The problem only seems to happen after Presto has been running for a
>> while and has processed several hundred queries. I?ve tried re-running
>> the queries that were running at the moment it crashed, but it does not
>> reproduce deterministically. Also, we don't see it in Java 7.
>> 
>> Thanks!
>> 
>> Martin
>> 
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140516/56d22ddf/attachment.html>

From bharadwaj.yadavalli at oracle.com  Sat May 17 01:46:08 2014
From: bharadwaj.yadavalli at oracle.com (S. Bharadwaj Yadavalli)
Date: Fri, 16 May 2014 21:46:08 -0400
Subject: segfault with 8u5
In-Reply-To: <CAEBmgdrQi-B_y+UERkx6eVK6F-rSV=n-7mXwAVoAcV+vGm4rvQ@mail.gmail.com>
References: <CAEBmgdrQi-B_y+UERkx6eVK6F-rSV=n-7mXwAVoAcV+vGm4rvQ@mail.gmail.com>
Message-ID: <5376BF60.5030405@oracle.com>


Martin,

I built Persto with 8u5. I see one test failure[1] - possibly this is known.

On 05/16/2014 03:39 PM, Martin Traverso wrote:
> We're testing Presto (https://github.com/facebook/presto) on Java 8, and
> ran into a segfault in the VM. Below is the relevant portion from the
> crash report. You can see the full dump here:
> https://gist.github.com/martint/364a12d4f776a6e54911

Irrespectively, would you be able to provide instructions to reproduce 
the above reported failure using the Presto build that I have?

Thanks,

Bharadwaj

[1]
Tests run: 49, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.903 
sec <<< FAILURE!
testRCText(com.facebook.presto.hive.TestHiveFileFormats)  Time elapsed: 
0.507 sec  <<< FAILURE!
java.lang.AssertionError: Wrong value for column 11 expected 
[1304665689123] but found [1304686389123]
	at org.testng.Assert.fail(Assert.java:94)
	at org.testng.Assert.failNotEquals(Assert.java:494)
	at org.testng.Assert.assertEquals(Assert.java:123)
	at 
com.facebook.presto.hive.AbstractTestHiveFileFormats.checkCursor(AbstractTestHiveFileFormats.java:318)
	at 
com.facebook.presto.hive.TestHiveFileFormats.testRCText(TestHiveFileFormats.java:64)

From ygaevsky at azulsystems.com  Sat May 17 02:15:36 2014
From: ygaevsky at azulsystems.com (Yuri Gaevsky)
Date: Sat, 17 May 2014 02:15:36 +0000
Subject: RFR(XXS): JDK-6883953 java -client -XX:ValueMapInitialSize=0
	crashes
In-Reply-To: <537688B5.2010507@oracle.com>
References: <ABC6F6B1F6CA734A9B233369A3750F15235161@MBX021-W3-CA-4.exch021.domain.local>
	<53753029.8070306@oracle.com> <537688B5.2010507@oracle.com>
Message-ID: <ABC6F6B1F6CA734A9B233369A3750F152398CC@MBX021-W3-CA-4.exch021.domain.local>

Thanks for your review,  Vladimir.

-Yuri

-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Saturday, May 17, 2014 1:53 AM
To: Yuri Gaevsky; hotspot-runtime-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
Cc: Niclas Adlertz
Subject: Re: RFR(XXS): JDK-6883953 java -client -XX:ValueMapInitialSize=0 crashes

Looks fine. I asked Niclas to sponsor this.

Thanks,
Vladimir

On 5/15/14 2:22 PM, Coleen Phillimore wrote:
>
> Hi Yuri,
> Since this is a compiler change, I'm including the compiler alias.
> Coleen
>
> On 5/15/14, 11:29 AM, Yuri Gaevsky wrote:
>> Hello.
>>
>> I am looking for a sponsor to review and to integrate this simple fix
>> into JDK 9:
>>
>> $ cat hotspot.patch
>> --- old/src/share/vm/runtime/arguments.cpp      2014-05-15
>> 18:43:52.907532800 +0400
>> +++ new/src/share/vm/runtime/arguments.cpp      2014-05-15
>> 18:43:52.595018700 +0400
>> @@ -2335,6 +2335,7 @@
>>     status = status && verify_percentage(MarkSweepDeadRatio,
>> "MarkSweepDeadRatio");
>>     status = status && verify_min_value(MarkSweepAlwaysCompactCount,
>> 1, "MarkSweepAlwaysCompactCount");
>> +  status = status && verify_min_value(ValueMapInitialSize, 1,
>> "ValueMapInitialSize");
>>     if (PrintNMTStatistics) {
>>   #if INCLUDE_NMT
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-6883953
>> Summary: Limit ValueMapInitialSize minimal value by 1.
>> Tests:  JCK-runtime-8 [api/[java_lang|java_util] & vm/] (Windows).
>>
>> Thank you,
>> -Yuri
>>
>


From niclas.adlertz at oracle.com  Mon May 19 10:17:31 2014
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Mon, 19 May 2014 12:17:31 +0200
Subject: RFR(XXS): JDK-6883953 java -client -XX:ValueMapInitialSize=0
	crashes
In-Reply-To: <ABC6F6B1F6CA734A9B233369A3750F152398CC@MBX021-W3-CA-4.exch021.domain.local>
References: <ABC6F6B1F6CA734A9B233369A3750F15235161@MBX021-W3-CA-4.exch021.domain.local>
	<53753029.8070306@oracle.com> <537688B5.2010507@oracle.com>
	<ABC6F6B1F6CA734A9B233369A3750F152398CC@MBX021-W3-CA-4.exch021.domain.local>
Message-ID: <5379DA3B.2020904@oracle.com>

Hi,

So tried to apply this patch on a x64 linux build. On x64 linux, the 
"-client" flag behaves strangely. From what I understand, the "-client" 
flag should be ignored on x64 linux.
Here is the output I'm getting with and without the patch applied and 
the "-client" flag.

*****************
Without the patch
*****************
# linux/linux_amd64_compiler2/debug/hotspot -XX:ValueMapInitialSize=0
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x00007f732d5ea6f3, pid=18993, tid=140131350521600
#
# JRE version: OpenJDK Runtime Environment (8.0) (build 
1.8.0-internal-adlertz_2013_12_04_14_49-b00)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-debug mixed 
mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x51e6f3]  ValueMap::entry_index(long, int)+0x1b

*****************************
Without the patch + "-client"
*****************************
# linux/linux_amd64_compiler2/debug/hotspot -client 
-XX:ValueMapInitialSize=0
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x00007fa7e86c3a8f, pid=19020, tid=140358227154688
#
# JRE version: OpenJDK Runtime Environment (8.0) (build 
1.8.0-internal-adlertz_2013_12_04_14_49-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.0-b61 mixed mode linux-amd64 
compressed oops)
# Problematic frame:
# V  [libjvm.so+0x387a8f]  ValueMap::find_insert(Instruction*)+0x3f

**************
With the patch
**************
# linux/linux_amd64_compiler2/debug/hotspot -XX:ValueMapInitialSize=0
ValueMapInitialSize of 0 is invalid; must be at least 1
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

**************************
With the patch + "-client"
**************************
# linux/linux_amd64_compiler2/debug/hotspot -client 
-XX:ValueMapInitialSize=0
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x00007fbf58cd0a8f, pid=19837, tid=140458963363584
#
# JRE version: OpenJDK Runtime Environment (8.0) (build 
1.8.0-internal-adlertz_2013_12_04_14_49-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.0-b61 mixed mode linux-amd64 
compressed oops)
# Problematic frame:
# V  [libjvm.so+0x387a8f]  ValueMap::find_insert(Instruction*)+0x3f


Should we file a separate bug for this and still push this fix?

Kind Regards,
Niclas Adlertz

On 05/17/2014 04:15 AM, Yuri Gaevsky wrote:
> Thanks for your review,  Vladimir.
>
> -Yuri
>
> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Saturday, May 17, 2014 1:53 AM
> To: Yuri Gaevsky; hotspot-runtime-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
> Cc: Niclas Adlertz
> Subject: Re: RFR(XXS): JDK-6883953 java -client -XX:ValueMapInitialSize=0 crashes
>
> Looks fine. I asked Niclas to sponsor this.
>
> Thanks,
> Vladimir
>
> On 5/15/14 2:22 PM, Coleen Phillimore wrote:
>>
>> Hi Yuri,
>> Since this is a compiler change, I'm including the compiler alias.
>> Coleen
>>
>> On 5/15/14, 11:29 AM, Yuri Gaevsky wrote:
>>> Hello.
>>>
>>> I am looking for a sponsor to review and to integrate this simple fix
>>> into JDK 9:
>>>
>>> $ cat hotspot.patch
>>> --- old/src/share/vm/runtime/arguments.cpp      2014-05-15
>>> 18:43:52.907532800 +0400
>>> +++ new/src/share/vm/runtime/arguments.cpp      2014-05-15
>>> 18:43:52.595018700 +0400
>>> @@ -2335,6 +2335,7 @@
>>>      status = status && verify_percentage(MarkSweepDeadRatio,
>>> "MarkSweepDeadRatio");
>>>      status = status && verify_min_value(MarkSweepAlwaysCompactCount,
>>> 1, "MarkSweepAlwaysCompactCount");
>>> +  status = status && verify_min_value(ValueMapInitialSize, 1,
>>> "ValueMapInitialSize");
>>>      if (PrintNMTStatistics) {
>>>    #if INCLUDE_NMT
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6883953
>>> Summary: Limit ValueMapInitialSize minimal value by 1.
>>> Tests:  JCK-runtime-8 [api/[java_lang|java_util] & vm/] (Windows).
>>>
>>> Thank you,
>>> -Yuri
>>>
>>
>

From roland.westrelin at oracle.com  Mon May 19 11:01:31 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 19 May 2014 13:01:31 +0200
Subject: RFR(M): 8026796: Make replace_in_map() on parent maps generic
Message-ID: <9F9E2688-4970-4282-A400-F44DB266B149@oracle.com>

This change reverts:

https://bugs.openjdk.java.net/browse/JDK-8024069

and propagates replacements in replace_in_map() to callers in a generic way. Every time replace_in_map() is called, the pair of nodes passed to replace_in_map is pushed on a list that the current map carries. When control flow paths merge, the lists for each of the control flow path?s maps are also merged. When parsing exits a method to return to a caller, the replaced nodes on the exit path are used to update the caller's map. This change also propagates replaced nodes after late inlining.

Roland.

From roland.westrelin at oracle.com  Mon May 19 11:37:45 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 19 May 2014 13:37:45 +0200
Subject: RFR(M): 8026796: Make replace_in_map() on parent maps generic
In-Reply-To: <9F9E2688-4970-4282-A400-F44DB266B149@oracle.com>
References: <9F9E2688-4970-4282-A400-F44DB266B149@oracle.com>
Message-ID: <8E791232-A0F6-4DC2-B40A-2C28D0E1159A@oracle.com>

I forgot the webrev:

http://cr.openjdk.java.net/~roland/8026796/webrev.00/

Roland.

On May 19, 2014, at 1:01 PM, Roland Westrelin <roland.westrelin at oracle.com> wrote:

> This change reverts:
> 
> https://bugs.openjdk.java.net/browse/JDK-8024069
> 
> and propagates replacements in replace_in_map() to callers in a generic way. Every time replace_in_map() is called, the pair of nodes passed to replace_in_map is pushed on a list that the current map carries. When control flow paths merge, the lists for each of the control flow path?s maps are also merged. When parsing exits a method to return to a caller, the replaced nodes on the exit path are used to update the caller's map. This change also propagates replaced nodes after late inlining.
> 
> Roland.


From david.holmes at oracle.com  Mon May 19 11:57:04 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 19 May 2014 21:57:04 +1000
Subject: RFR(XXS): JDK-6883953 java -client -XX:ValueMapInitialSize=0
	crashes
In-Reply-To: <5379DA3B.2020904@oracle.com>
References: <ABC6F6B1F6CA734A9B233369A3750F15235161@MBX021-W3-CA-4.exch021.domain.local>	<53753029.8070306@oracle.com>
	<537688B5.2010507@oracle.com>	<ABC6F6B1F6CA734A9B233369A3750F152398CC@MBX021-W3-CA-4.exch021.domain.local>
	<5379DA3B.2020904@oracle.com>
Message-ID: <5379F190.6040200@oracle.com>

Hi Niclas,

On 19/05/2014 8:17 PM, Niclas Adlertz wrote:
> Hi,
>
> So tried to apply this patch on a x64 linux build. On x64 linux, the
> "-client" flag behaves strangely. From what I understand, the "-client"
> flag should be ignored on x64 linux.
> Here is the output I'm getting with and without the patch applied and
> the "-client" flag.
>
> *****************
> Without the patch
> *****************
> # linux/linux_amd64_compiler2/debug/hotspot -XX:ValueMapInitialSize=0

What launcher are you using here ??

David


> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGFPE (0x8) at pc=0x00007f732d5ea6f3, pid=18993, tid=140131350521600
> #
> # JRE version: OpenJDK Runtime Environment (8.0) (build
> 1.8.0-internal-adlertz_2013_12_04_14_49-b00)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-debug mixed
> mode linux-amd64 compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x51e6f3]  ValueMap::entry_index(long, int)+0x1b
>
> *****************************
> Without the patch + "-client"
> *****************************
> # linux/linux_amd64_compiler2/debug/hotspot -client
> -XX:ValueMapInitialSize=0
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGFPE (0x8) at pc=0x00007fa7e86c3a8f, pid=19020, tid=140358227154688
> #
> # JRE version: OpenJDK Runtime Environment (8.0) (build
> 1.8.0-internal-adlertz_2013_12_04_14_49-b00)
> # Java VM: OpenJDK 64-Bit Server VM (25.0-b61 mixed mode linux-amd64
> compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x387a8f]  ValueMap::find_insert(Instruction*)+0x3f
>
> **************
> With the patch
> **************
> # linux/linux_amd64_compiler2/debug/hotspot -XX:ValueMapInitialSize=0
> ValueMapInitialSize of 0 is invalid; must be at least 1
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
>
> **************************
> With the patch + "-client"
> **************************
> # linux/linux_amd64_compiler2/debug/hotspot -client
> -XX:ValueMapInitialSize=0
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGFPE (0x8) at pc=0x00007fbf58cd0a8f, pid=19837, tid=140458963363584
> #
> # JRE version: OpenJDK Runtime Environment (8.0) (build
> 1.8.0-internal-adlertz_2013_12_04_14_49-b00)
> # Java VM: OpenJDK 64-Bit Server VM (25.0-b61 mixed mode linux-amd64
> compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x387a8f]  ValueMap::find_insert(Instruction*)+0x3f
>
>
> Should we file a separate bug for this and still push this fix?
>
> Kind Regards,
> Niclas Adlertz
>
> On 05/17/2014 04:15 AM, Yuri Gaevsky wrote:
>> Thanks for your review,  Vladimir.
>>
>> -Yuri
>>
>> -----Original Message-----
>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>> Sent: Saturday, May 17, 2014 1:53 AM
>> To: Yuri Gaevsky; hotspot-runtime-dev at openjdk.java.net;
>> hotspot-compiler-dev at openjdk.java.net
>> Cc: Niclas Adlertz
>> Subject: Re: RFR(XXS): JDK-6883953 java -client
>> -XX:ValueMapInitialSize=0 crashes
>>
>> Looks fine. I asked Niclas to sponsor this.
>>
>> Thanks,
>> Vladimir
>>
>> On 5/15/14 2:22 PM, Coleen Phillimore wrote:
>>>
>>> Hi Yuri,
>>> Since this is a compiler change, I'm including the compiler alias.
>>> Coleen
>>>
>>> On 5/15/14, 11:29 AM, Yuri Gaevsky wrote:
>>>> Hello.
>>>>
>>>> I am looking for a sponsor to review and to integrate this simple fix
>>>> into JDK 9:
>>>>
>>>> $ cat hotspot.patch
>>>> --- old/src/share/vm/runtime/arguments.cpp      2014-05-15
>>>> 18:43:52.907532800 +0400
>>>> +++ new/src/share/vm/runtime/arguments.cpp      2014-05-15
>>>> 18:43:52.595018700 +0400
>>>> @@ -2335,6 +2335,7 @@
>>>>      status = status && verify_percentage(MarkSweepDeadRatio,
>>>> "MarkSweepDeadRatio");
>>>>      status = status && verify_min_value(MarkSweepAlwaysCompactCount,
>>>> 1, "MarkSweepAlwaysCompactCount");
>>>> +  status = status && verify_min_value(ValueMapInitialSize, 1,
>>>> "ValueMapInitialSize");
>>>>      if (PrintNMTStatistics) {
>>>>    #if INCLUDE_NMT
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6883953
>>>> Summary: Limit ValueMapInitialSize minimal value by 1.
>>>> Tests:  JCK-runtime-8 [api/[java_lang|java_util] & vm/] (Windows).
>>>>
>>>> Thank you,
>>>> -Yuri
>>>>
>>>
>>

From david.holmes at oracle.com  Mon May 19 12:07:37 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 19 May 2014 22:07:37 +1000
Subject: RFR(XXS): JDK-6883953 java -client -XX:ValueMapInitialSize=0
	crashes
In-Reply-To: <5379F190.6040200@oracle.com>
References: <ABC6F6B1F6CA734A9B233369A3750F15235161@MBX021-W3-CA-4.exch021.domain.local>	<53753029.8070306@oracle.com>	<537688B5.2010507@oracle.com>	<ABC6F6B1F6CA734A9B233369A3750F152398CC@MBX021-W3-CA-4.exch021.domain.local>	<5379DA3B.2020904@oracle.com>
	<5379F190.6040200@oracle.com>
Message-ID: <5379F409.9060600@oracle.com>

On 19/05/2014 9:57 PM, David Holmes wrote:
> Hi Niclas,
>
> On 19/05/2014 8:17 PM, Niclas Adlertz wrote:
>> Hi,
>>
>> So tried to apply this patch on a x64 linux build. On x64 linux, the
>> "-client" flag behaves strangely. From what I understand, the "-client"
>> flag should be ignored on x64 linux.
>> Here is the output I'm getting with and without the patch applied and
>> the "-client" flag.
>>
>> *****************
>> Without the patch
>> *****************
>> # linux/linux_amd64_compiler2/debug/hotspot -XX:ValueMapInitialSize=0
>
> What launcher are you using here ??

Never mind I just located the script. I never knew that existed!

It looks like if you use -client/-server on the invocation it overrides 
the -XXaltjvm setting. So what you are executing in the "patched + 
-client" case is the server VM from the host JRE/JDK.

David
-----

> David
>
>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGFPE (0x8) at pc=0x00007f732d5ea6f3, pid=18993, tid=140131350521600
>> #
>> # JRE version: OpenJDK Runtime Environment (8.0) (build
>> 1.8.0-internal-adlertz_2013_12_04_14_49-b00)
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-debug mixed
>> mode linux-amd64 compressed oops)
>> # Problematic frame:
>> # V  [libjvm.so+0x51e6f3]  ValueMap::entry_index(long, int)+0x1b
>>
>> *****************************
>> Without the patch + "-client"
>> *****************************
>> # linux/linux_amd64_compiler2/debug/hotspot -client
>> -XX:ValueMapInitialSize=0
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGFPE (0x8) at pc=0x00007fa7e86c3a8f, pid=19020, tid=140358227154688
>> #
>> # JRE version: OpenJDK Runtime Environment (8.0) (build
>> 1.8.0-internal-adlertz_2013_12_04_14_49-b00)
>> # Java VM: OpenJDK 64-Bit Server VM (25.0-b61 mixed mode linux-amd64
>> compressed oops)
>> # Problematic frame:
>> # V  [libjvm.so+0x387a8f]  ValueMap::find_insert(Instruction*)+0x3f
>>
>> **************
>> With the patch
>> **************
>> # linux/linux_amd64_compiler2/debug/hotspot -XX:ValueMapInitialSize=0
>> ValueMapInitialSize of 0 is invalid; must be at least 1
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>>
>> **************************
>> With the patch + "-client"
>> **************************
>> # linux/linux_amd64_compiler2/debug/hotspot -client
>> -XX:ValueMapInitialSize=0
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGFPE (0x8) at pc=0x00007fbf58cd0a8f, pid=19837, tid=140458963363584
>> #
>> # JRE version: OpenJDK Runtime Environment (8.0) (build
>> 1.8.0-internal-adlertz_2013_12_04_14_49-b00)
>> # Java VM: OpenJDK 64-Bit Server VM (25.0-b61 mixed mode linux-amd64
>> compressed oops)
>> # Problematic frame:
>> # V  [libjvm.so+0x387a8f]  ValueMap::find_insert(Instruction*)+0x3f
>>
>>
>> Should we file a separate bug for this and still push this fix?
>>
>> Kind Regards,
>> Niclas Adlertz
>>
>> On 05/17/2014 04:15 AM, Yuri Gaevsky wrote:
>>> Thanks for your review,  Vladimir.
>>>
>>> -Yuri
>>>
>>> -----Original Message-----
>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>> Sent: Saturday, May 17, 2014 1:53 AM
>>> To: Yuri Gaevsky; hotspot-runtime-dev at openjdk.java.net;
>>> hotspot-compiler-dev at openjdk.java.net
>>> Cc: Niclas Adlertz
>>> Subject: Re: RFR(XXS): JDK-6883953 java -client
>>> -XX:ValueMapInitialSize=0 crashes
>>>
>>> Looks fine. I asked Niclas to sponsor this.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/15/14 2:22 PM, Coleen Phillimore wrote:
>>>>
>>>> Hi Yuri,
>>>> Since this is a compiler change, I'm including the compiler alias.
>>>> Coleen
>>>>
>>>> On 5/15/14, 11:29 AM, Yuri Gaevsky wrote:
>>>>> Hello.
>>>>>
>>>>> I am looking for a sponsor to review and to integrate this simple fix
>>>>> into JDK 9:
>>>>>
>>>>> $ cat hotspot.patch
>>>>> --- old/src/share/vm/runtime/arguments.cpp      2014-05-15
>>>>> 18:43:52.907532800 +0400
>>>>> +++ new/src/share/vm/runtime/arguments.cpp      2014-05-15
>>>>> 18:43:52.595018700 +0400
>>>>> @@ -2335,6 +2335,7 @@
>>>>>      status = status && verify_percentage(MarkSweepDeadRatio,
>>>>> "MarkSweepDeadRatio");
>>>>>      status = status && verify_min_value(MarkSweepAlwaysCompactCount,
>>>>> 1, "MarkSweepAlwaysCompactCount");
>>>>> +  status = status && verify_min_value(ValueMapInitialSize, 1,
>>>>> "ValueMapInitialSize");
>>>>>      if (PrintNMTStatistics) {
>>>>>    #if INCLUDE_NMT
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6883953
>>>>> Summary: Limit ValueMapInitialSize minimal value by 1.
>>>>> Tests:  JCK-runtime-8 [api/[java_lang|java_util] & vm/] (Windows).
>>>>>
>>>>> Thank you,
>>>>> -Yuri
>>>>>
>>>>
>>>

From niclas.adlertz at oracle.com  Mon May 19 12:26:41 2014
From: niclas.adlertz at oracle.com (Niclas Adlertz)
Date: Mon, 19 May 2014 14:26:41 +0200
Subject: RFR(XXS): JDK-6883953 java -client -XX:ValueMapInitialSize=0
	crashes
In-Reply-To: <5379F409.9060600@oracle.com>
References: <ABC6F6B1F6CA734A9B233369A3750F15235161@MBX021-W3-CA-4.exch021.domain.local>	<53753029.8070306@oracle.com>	<537688B5.2010507@oracle.com>	<ABC6F6B1F6CA734A9B233369A3750F152398CC@MBX021-W3-CA-4.exch021.domain.local>	<5379DA3B.2020904@oracle.com>
	<5379F190.6040200@oracle.com> <5379F409.9060600@oracle.com>
Message-ID: <5379F881.1020108@oracle.com>

Hi David,

Ah I see, and since the libjvm.so at the host JDK is a fastdebug build, 
the call to ValueMap::entry_index() has been inlined in 
ValueMap::find_insert(). That's why I'm seing a crash inside 
ValueMap::find_insert().

Thanks, then this is not an issue.

Kind Regards,
Niclas Adlertz

On 05/19/2014 02:07 PM, David Holmes wrote:
> On 19/05/2014 9:57 PM, David Holmes wrote:
>> Hi Niclas,
>>
>> On 19/05/2014 8:17 PM, Niclas Adlertz wrote:
>>> Hi,
>>>
>>> So tried to apply this patch on a x64 linux build. On x64 linux, the
>>> "-client" flag behaves strangely. From what I understand, the "-client"
>>> flag should be ignored on x64 linux.
>>> Here is the output I'm getting with and without the patch applied and
>>> the "-client" flag.
>>>
>>> *****************
>>> Without the patch
>>> *****************
>>> # linux/linux_amd64_compiler2/debug/hotspot -XX:ValueMapInitialSize=0
>>
>> What launcher are you using here ??
>
> Never mind I just located the script. I never knew that existed!
>
> It looks like if you use -client/-server on the invocation it overrides
> the -XXaltjvm setting. So what you are executing in the "patched +
> -client" case is the server VM from the host JRE/JDK.
>
> David
> -----
>
>> David
>>
>>
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  SIGFPE (0x8) at pc=0x00007f732d5ea6f3, pid=18993, tid=140131350521600
>>> #
>>> # JRE version: OpenJDK Runtime Environment (8.0) (build
>>> 1.8.0-internal-adlertz_2013_12_04_14_49-b00)
>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-debug mixed
>>> mode linux-amd64 compressed oops)
>>> # Problematic frame:
>>> # V  [libjvm.so+0x51e6f3]  ValueMap::entry_index(long, int)+0x1b
>>>
>>> *****************************
>>> Without the patch + "-client"
>>> *****************************
>>> # linux/linux_amd64_compiler2/debug/hotspot -client
>>> -XX:ValueMapInitialSize=0
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  SIGFPE (0x8) at pc=0x00007fa7e86c3a8f, pid=19020, tid=140358227154688
>>> #
>>> # JRE version: OpenJDK Runtime Environment (8.0) (build
>>> 1.8.0-internal-adlertz_2013_12_04_14_49-b00)
>>> # Java VM: OpenJDK 64-Bit Server VM (25.0-b61 mixed mode linux-amd64
>>> compressed oops)
>>> # Problematic frame:
>>> # V  [libjvm.so+0x387a8f]  ValueMap::find_insert(Instruction*)+0x3f
>>>
>>> **************
>>> With the patch
>>> **************
>>> # linux/linux_amd64_compiler2/debug/hotspot -XX:ValueMapInitialSize=0
>>> ValueMapInitialSize of 0 is invalid; must be at least 1
>>> Error: Could not create the Java Virtual Machine.
>>> Error: A fatal exception has occurred. Program will exit.
>>>
>>> **************************
>>> With the patch + "-client"
>>> **************************
>>> # linux/linux_amd64_compiler2/debug/hotspot -client
>>> -XX:ValueMapInitialSize=0
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  SIGFPE (0x8) at pc=0x00007fbf58cd0a8f, pid=19837, tid=140458963363584
>>> #
>>> # JRE version: OpenJDK Runtime Environment (8.0) (build
>>> 1.8.0-internal-adlertz_2013_12_04_14_49-b00)
>>> # Java VM: OpenJDK 64-Bit Server VM (25.0-b61 mixed mode linux-amd64
>>> compressed oops)
>>> # Problematic frame:
>>> # V  [libjvm.so+0x387a8f]  ValueMap::find_insert(Instruction*)+0x3f
>>>
>>>
>>> Should we file a separate bug for this and still push this fix?
>>>
>>> Kind Regards,
>>> Niclas Adlertz
>>>
>>> On 05/17/2014 04:15 AM, Yuri Gaevsky wrote:
>>>> Thanks for your review,  Vladimir.
>>>>
>>>> -Yuri
>>>>
>>>> -----Original Message-----
>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
>>>> Sent: Saturday, May 17, 2014 1:53 AM
>>>> To: Yuri Gaevsky; hotspot-runtime-dev at openjdk.java.net;
>>>> hotspot-compiler-dev at openjdk.java.net
>>>> Cc: Niclas Adlertz
>>>> Subject: Re: RFR(XXS): JDK-6883953 java -client
>>>> -XX:ValueMapInitialSize=0 crashes
>>>>
>>>> Looks fine. I asked Niclas to sponsor this.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 5/15/14 2:22 PM, Coleen Phillimore wrote:
>>>>>
>>>>> Hi Yuri,
>>>>> Since this is a compiler change, I'm including the compiler alias.
>>>>> Coleen
>>>>>
>>>>> On 5/15/14, 11:29 AM, Yuri Gaevsky wrote:
>>>>>> Hello.
>>>>>>
>>>>>> I am looking for a sponsor to review and to integrate this simple fix
>>>>>> into JDK 9:
>>>>>>
>>>>>> $ cat hotspot.patch
>>>>>> --- old/src/share/vm/runtime/arguments.cpp      2014-05-15
>>>>>> 18:43:52.907532800 +0400
>>>>>> +++ new/src/share/vm/runtime/arguments.cpp      2014-05-15
>>>>>> 18:43:52.595018700 +0400
>>>>>> @@ -2335,6 +2335,7 @@
>>>>>>      status = status && verify_percentage(MarkSweepDeadRatio,
>>>>>> "MarkSweepDeadRatio");
>>>>>>      status = status && verify_min_value(MarkSweepAlwaysCompactCount,
>>>>>> 1, "MarkSweepAlwaysCompactCount");
>>>>>> +  status = status && verify_min_value(ValueMapInitialSize, 1,
>>>>>> "ValueMapInitialSize");
>>>>>>      if (PrintNMTStatistics) {
>>>>>>    #if INCLUDE_NMT
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6883953
>>>>>> Summary: Limit ValueMapInitialSize minimal value by 1.
>>>>>> Tests:  JCK-runtime-8 [api/[java_lang|java_util] & vm/] (Windows).
>>>>>>
>>>>>> Thank you,
>>>>>> -Yuri
>>>>>>
>>>>>
>>>>

From bharadwaj.yadavalli at oracle.com  Mon May 19 15:42:09 2014
From: bharadwaj.yadavalli at oracle.com (S. Bharadwaj Yadavalli)
Date: Mon, 19 May 2014 11:42:09 -0400
Subject: RFR (XS):   JDK-6563994 - assert(wf.check_method_context(ctxk, m),
	"proper context") failed
Message-ID: <537A2651.8090907@oracle.com>

I would like to get reviews for a small fix for the occasional nightly 
failures reported in https://bugs.openjdk.java.net/browse/JDK-6563994

The assertion is observed to be triggered while looking up for a 
monomorphic call target. It happens in a rare situation, where the 
method holder class is redefined at safepoints *after* resolution of the 
target method's class (in find_monomorphic_target() - 
src/share/vm/ci/ciMethod.cpp:694) but *before* the call of 
find_unique_concrete_method() - src/share/vm/ci/ciMethod.cpp:733). This 
change returns NULL for a such a redefined method which would be marked 
as old, indicating that candidate call target may not be inlined, since 
all we have is a pointer to an old method that has been redefined. The 
subsequent assertion of check_method_context for old methods is not 
applicable and hence not done for such methods.

Testing:

Without the fix: Was able to trigger the assertion upon running the test 
nsk.jvmti.RetransformClasses.retransform001 a few hundred times.

With the fix: Was able to run the test for over 3000 iterations 
continuously for more than 3 days without triggering the assertion.

Ran JPRT tests successfully

webrev: http://cr.openjdk.java.net/~bharadwaj/6563994/webrev_0/
bug: https://bugs.openjdk.java.net/browse/JDK-6563994

Thanks,

Bharadwaj

From igor.ignatyev at oracle.com  Mon May 19 15:59:23 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 19 May 2014 19:59:23 +0400
Subject: RFR(XXS) : 8032498: compiler/ciReplay tests fail with StatusError:
	failed to clean up files after test...
Message-ID: <537A2A5B.1000904@oracle.com>

http://cr.openjdk.java.net/~iignatyev/8032498/webrev.00/
8 lines changed: 6 ins; 2 del; 0 mod;

Hi all,

Please review patch:

Problem:
if java doesn't crash in 'generate_replay' function due to some reasons, 
e.g. incompatible vm options like '-XX:CICompilerCount=1' (fixed by 
8038393) or problems w/ ulimit (fixed by 8032662), 'core_locations' 
variable will be an empty string, test will try to copy root directory 
to current directory, as a result jtreg will fail to clean up the directory

Fix:
fail tests w/ message about an absence of core file location, if 
'core_locations' variable is empty

jbs: https://bugs.openjdk.java.net/browse/JDK-8032498
testing:
  - failing tests in jprt
  - locally verified, that tests w/o fixes for 8038393, 8032662 fail as 
expected

-- 
Igor

From christian.thalinger at oracle.com  Mon May 19 16:37:16 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Mon, 19 May 2014 09:37:16 -0700
Subject: RFR (XS):   JDK-6563994 - assert(wf.check_method_context(ctxk, m),
	"proper context") failed
In-Reply-To: <537A2651.8090907@oracle.com>
References: <537A2651.8090907@oracle.com>
Message-ID: <5604F6A3-5111-48C7-AC55-808EAF975325@oracle.com>

As Tom states in the bug report there is no easy way to fix this comprehensively.  The fix you?re proposing is a bandaid fix and don?t really like it.  That said, I can't think of a better way so I?m ok with the fix.

On May 19, 2014, at 8:42 AM, S. Bharadwaj Yadavalli <bharadwaj.yadavalli at oracle.com> wrote:

> I would like to get reviews for a small fix for the occasional nightly failures reported in https://bugs.openjdk.java.net/browse/JDK-6563994
> 
> The assertion is observed to be triggered while looking up for a monomorphic call target. It happens in a rare situation, where the method holder class is redefined at safepoints *after* resolution of the target method's class (in find_monomorphic_target() - src/share/vm/ci/ciMethod.cpp:694) but *before* the call of find_unique_concrete_method() - src/share/vm/ci/ciMethod.cpp:733). This change returns NULL for a such a redefined method which would be marked as old, indicating that candidate call target may not be inlined, since all we have is a pointer to an old method that has been redefined. The subsequent assertion of check_method_context for old methods is not applicable and hence not done for such methods.
> 
> Testing:
> 
> Without the fix: Was able to trigger the assertion upon running the test nsk.jvmti.RetransformClasses.retransform001 a few hundred times.
> 
> With the fix: Was able to run the test for over 3000 iterations continuously for more than 3 days without triggering the assertion.
> 
> Ran JPRT tests successfully
> 
> webrev: http://cr.openjdk.java.net/~bharadwaj/6563994/webrev_0/
> bug: https://bugs.openjdk.java.net/browse/JDK-6563994
> 
> Thanks,
> 
> Bharadwaj


From vladimir.kozlov at oracle.com  Mon May 19 17:33:18 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 19 May 2014 10:33:18 -0700
Subject: RFR (XS):   JDK-6563994 - assert(wf.check_method_context(ctxk,
	m), "proper context") failed
In-Reply-To: <537A2651.8090907@oracle.com>
References: <537A2651.8090907@oracle.com>
Message-ID: <537A405E.5050509@oracle.com>

Good.

Vladimir

On 5/19/14 8:42 AM, S. Bharadwaj Yadavalli wrote:
> I would like to get reviews for a small fix for the occasional nightly failures reported in
> https://bugs.openjdk.java.net/browse/JDK-6563994
>
> The assertion is observed to be triggered while looking up for a monomorphic call target. It happens in a rare
> situation, where the method holder class is redefined at safepoints *after* resolution of the target method's class (in
> find_monomorphic_target() - src/share/vm/ci/ciMethod.cpp:694) but *before* the call of find_unique_concrete_method() -
> src/share/vm/ci/ciMethod.cpp:733). This change returns NULL for a such a redefined method which would be marked as old,
> indicating that candidate call target may not be inlined, since all we have is a pointer to an old method that has been
> redefined. The subsequent assertion of check_method_context for old methods is not applicable and hence not done for
> such methods.
>
> Testing:
>
> Without the fix: Was able to trigger the assertion upon running the test nsk.jvmti.RetransformClasses.retransform001 a
> few hundred times.
>
> With the fix: Was able to run the test for over 3000 iterations continuously for more than 3 days without triggering the
> assertion.
>
> Ran JPRT tests successfully
>
> webrev: http://cr.openjdk.java.net/~bharadwaj/6563994/webrev_0/
> bug: https://bugs.openjdk.java.net/browse/JDK-6563994
>
> Thanks,
>
> Bharadwaj

From vladimir.kozlov at oracle.com  Mon May 19 17:34:31 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 19 May 2014 10:34:31 -0700
Subject: RFR(XXS) : 8032498: compiler/ciReplay tests fail with StatusError:
	failed to clean up files after test...
In-Reply-To: <537A2A5B.1000904@oracle.com>
References: <537A2A5B.1000904@oracle.com>
Message-ID: <537A40A7.5000503@oracle.com>

Good.

Vladimir

On 5/19/14 8:59 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8032498/webrev.00/
> 8 lines changed: 6 ins; 2 del; 0 mod;
>
> Hi all,
>
> Please review patch:
>
> Problem:
> if java doesn't crash in 'generate_replay' function due to some reasons, e.g. incompatible vm options like
> '-XX:CICompilerCount=1' (fixed by 8038393) or problems w/ ulimit (fixed by 8032662), 'core_locations' variable will be
> an empty string, test will try to copy root directory to current directory, as a result jtreg will fail to clean up the
> directory
>
> Fix:
> fail tests w/ message about an absence of core file location, if 'core_locations' variable is empty
>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8032498
> testing:
>   - failing tests in jprt
>   - locally verified, that tests w/o fixes for 8038393, 8032662 fail as expected
>

From mtraverso at gmail.com  Mon May 19 19:24:40 2014
From: mtraverso at gmail.com (Martin Traverso)
Date: Mon, 19 May 2014 12:24:40 -0700
Subject: segfault with 8u5
In-Reply-To: <53768534.7050601@oracle.com>
References: <CAEBmgdrQi-B_y+UERkx6eVK6F-rSV=n-7mXwAVoAcV+vGm4rvQ@mail.gmail.com>
	<53768534.7050601@oracle.com>
Message-ID: <CAEBmgdpPNC6mUAQso2wpw9m5XA2ZCMh2Uxq-OvkTwvu5A+MKHA@mail.gmail.com>

>
> The failure happened in C1 JIT compiler (first tier). You can try to
> switch off -XX:-TieredCompilation.
>

That seemed to have worked around this particular issue.

However, we ran into another crash:

Stack: [0x00000000430c8000,0x00000000431c9000],
sp=0x00000000431c5980,  free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x814115]  LoadKlassNode::make(PhaseGVN&, Node*, Node*,
TypePtr const*, TypeKlassPtr const*)+0x45
V  [libjvm.so+0x51ab06]  Parse::catch_inline_exceptions(SafePointNode*)+0x936
V  [libjvm.so+0x8c1a5a]  Parse::do_exceptions()+0xba
V  [libjvm.so+0x8c6100]  Parse::do_one_block()+0x180
V  [libjvm.so+0x8c6377]  Parse::do_all_blocks()+0x127
V  [libjvm.so+0x8c95d3]  Parse::Parse(JVMState*, ciMethod*, float,
Parse*)+0x15a3
V  [libjvm.so+0x3b6529]  ParseGenerator::generate(JVMState*, Parse*)+0x99
V  [libjvm.so+0x3b7202]  PredictedCallGenerator::generate(JVMState*,
Parse*)+0x2a2
V  [libjvm.so+0x51aefd]  Parse::do_call()+0x1cd
V  [libjvm.so+0x8d3c7a]  Parse::do_one_bytecode()+0x32da
V  [libjvm.so+0x8c60f8]  Parse::do_one_block()+0x178
V  [libjvm.so+0x8c6377]  Parse::do_all_blocks()+0x127
V  [libjvm.so+0x8c95d3]  Parse::Parse(JVMState*, ciMethod*, float,
Parse*)+0x15a3
V  [libjvm.so+0x3b6529]  ParseGenerator::generate(JVMState*, Parse*)+0x99
V  [libjvm.so+0x46111c]  Compile::Compile(ciEnv*, C2Compiler*,
ciMethod*, int, bool, bool, bool)+0x128c
V  [libjvm.so+0x3b5008]  C2Compiler::compile_method(ciEnv*, ciMethod*,
int)+0x198
V  [libjvm.so+0x46982a]
CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc8a
V  [libjvm.so+0x46c230]  CompileBroker::compiler_thread_loop()+0x620
V  [libjvm.so+0x9e303f]  JavaThread::thread_main_inner()+0xdf
V  [libjvm.so+0x9e3205]  JavaThread::run()+0x1b5
V  [libjvm.so+0x8a00c8]  java_start(Thread*)+0x108



Full dump here: https://gist.github.com/martint/783cf3e30c17fc897423


The only bug I found which could be related is next:
>
> https://bugs.openjdk.java.net/browse/JDK-8029381
>
>
Unfortunately, I can't see this bug report. I get redirected to the login
screen.


Thanks!
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140519/bb6a617e/attachment-0001.html>

From bharadwaj.yadavalli at oracle.com  Mon May 19 20:06:57 2014
From: bharadwaj.yadavalli at oracle.com (S. Bharadwaj Yadavalli)
Date: Mon, 19 May 2014 16:06:57 -0400
Subject: RFR (XS):   JDK-6563994 - assert(wf.check_method_context(ctxk,
	m), "proper context") failed
In-Reply-To: <537A405E.5050509@oracle.com>
References: <537A2651.8090907@oracle.com> <537A405E.5050509@oracle.com>
Message-ID: <537A6461.2000803@oracle.com>

Thanks for the reviews, Christian and Vladimir.

Bharadwaj

On 05/19/2014 01:33 PM, Vladimir Kozlov wrote:
> Good.
>
> Vladimir
>
> On 5/19/14 8:42 AM, S. Bharadwaj Yadavalli wrote:
>> I would like to get reviews for a small fix for the occasional nightly
>> failures reported in
>> https://bugs.openjdk.java.net/browse/JDK-6563994
>>
>> The assertion is observed to be triggered while looking up for a
>> monomorphic call target. It happens in a rare
>> situation, where the method holder class is redefined at safepoints
>> *after* resolution of the target method's class (in
>> find_monomorphic_target() - src/share/vm/ci/ciMethod.cpp:694) but
>> *before* the call of find_unique_concrete_method() -
>> src/share/vm/ci/ciMethod.cpp:733). This change returns NULL for a such
>> a redefined method which would be marked as old,
>> indicating that candidate call target may not be inlined, since all we
>> have is a pointer to an old method that has been
>> redefined. The subsequent assertion of check_method_context for old
>> methods is not applicable and hence not done for
>> such methods.
>>
>> Testing:
>>
>> Without the fix: Was able to trigger the assertion upon running the
>> test nsk.jvmti.RetransformClasses.retransform001 a
>> few hundred times.
>>
>> With the fix: Was able to run the test for over 3000 iterations
>> continuously for more than 3 days without triggering the
>> assertion.
>>
>> Ran JPRT tests successfully
>>
>> webrev: http://cr.openjdk.java.net/~bharadwaj/6563994/webrev_0/
>> bug: https://bugs.openjdk.java.net/browse/JDK-6563994
>>
>> Thanks,
>>
>> Bharadwaj

From vladimir.kozlov at oracle.com  Mon May 19 23:37:58 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 19 May 2014 16:37:58 -0700
Subject: RFR(M): 8026796: Make replace_in_map() on parent maps generic
In-Reply-To: <8E791232-A0F6-4DC2-B40A-2C28D0E1159A@oracle.com>
References: <9F9E2688-4970-4282-A400-F44DB266B149@oracle.com>
	<8E791232-A0F6-4DC2-B40A-2C28D0E1159A@oracle.com>
Message-ID: <537A95D6.9020603@oracle.com>

Why previous code 8024069 does not work?

'before', 'after' may not good names. You call new nodes 'improved' in 
the comment you should use it.

You meaningful names (not o,n) in record(Node* o, Node* n).

It would be nice to use getter/setter functions:

ReplacedNodes r = kit.map()->_replaced_nodes;
kit.map()->_replaced_nodes = r;

Do you have cases when ReplacedNodes could be repopulated? So that we 
reset length GrowableArray::clear() instead of trashing pointer:

+void ReplacedNodes::reset() {
+  _replaced_nodes = NULL;
+}

I don't see cleanup of ReplacedNodes in Node::destruct() and other 
places where we clean up expensive nodes, for example.

Is the code in Parse::create_entry_map() correct? First, you destroy 
ReplacedNodes:

   _caller->map()->delete_replaced_nodes();

then you used it to initialize new map:

   SafePointNode* inmap = _caller->map();
   map()->transfer_replaced_nodes_from(inmap, _new_idx);


Thanks,
Vladimir

On 5/19/14 4:37 AM, Roland Westrelin wrote:
> I forgot the webrev:
>
> http://cr.openjdk.java.net/~roland/8026796/webrev.00/
>
> Roland.
>
> On May 19, 2014, at 1:01 PM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
>
>> This change reverts:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8024069
>>
>> and propagates replacements in replace_in_map() to callers in a generic way. Every time replace_in_map() is called, the pair of nodes passed to replace_in_map is pushed on a list that the current map carries. When control flow paths merge, the lists for each of the control flow path?s maps are also merged. When parsing exits a method to return to a caller, the replaced nodes on the exit path are used to update the caller's map. This change also propagates replaced nodes after late inlining.
>>
>> Roland.
>

From igor.ignatyev at oracle.com  Tue May 20 06:56:18 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 20 May 2014 10:56:18 +0400
Subject: RFR(XXS) : 8032498: compiler/ciReplay tests fail with StatusError:
	failed to clean up files after test...
In-Reply-To: <537A40A7.5000503@oracle.com>
References: <537A2A5B.1000904@oracle.com> <537A40A7.5000503@oracle.com>
Message-ID: <537AFC92.7050109@oracle.com>

Vladimir,

Thanks for review.

Igor

On 05/19/2014 09:34 PM, Vladimir Kozlov wrote:
> Good.
>
> Vladimir
>
> On 5/19/14 8:59 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/8032498/webrev.00/
>> 8 lines changed: 6 ins; 2 del; 0 mod;
>>
>> Hi all,
>>
>> Please review patch:
>>
>> Problem:
>> if java doesn't crash in 'generate_replay' function due to some
>> reasons, e.g. incompatible vm options like
>> '-XX:CICompilerCount=1' (fixed by 8038393) or problems w/ ulimit
>> (fixed by 8032662), 'core_locations' variable will be
>> an empty string, test will try to copy root directory to current
>> directory, as a result jtreg will fail to clean up the
>> directory
>>
>> Fix:
>> fail tests w/ message about an absence of core file location, if
>> 'core_locations' variable is empty
>>
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8032498
>> testing:
>>   - failing tests in jprt
>>   - locally verified, that tests w/o fixes for 8038393, 8032662 fail
>> as expected
>>

From roland.westrelin at oracle.com  Tue May 20 15:47:09 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Tue, 20 May 2014 17:47:09 +0200
Subject: RFR(M): 8026796: Make replace_in_map() on parent maps generic
In-Reply-To: <537A95D6.9020603@oracle.com>
References: <9F9E2688-4970-4282-A400-F44DB266B149@oracle.com>
	<8E791232-A0F6-4DC2-B40A-2C28D0E1159A@oracle.com>
	<537A95D6.9020603@oracle.com>
Message-ID: <B26AC6C5-5A7E-428C-8EA9-B2910EB44065@oracle.com>

Hi Vladimir,

Thanks for taking a look at this.

> Why previous code 8024069 does not work?

The previous code works but this one improves and replaces it. When 8024069 was reviewed, you asked for a generic fix:

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-October/012215.html

I will work on your other comments and send an updated webrev.

Roland.

> 'before', 'after' may not good names. You call new nodes 'improved' in the comment you should use it.
> 
> You meaningful names (not o,n) in record(Node* o, Node* n).
> 
> It would be nice to use getter/setter functions:
> 
> ReplacedNodes r = kit.map()->_replaced_nodes;
> kit.map()->_replaced_nodes = r;
> 
> Do you have cases when ReplacedNodes could be repopulated? So that we reset length GrowableArray::clear() instead of trashing pointer:
> 
> +void ReplacedNodes::reset() {
> +  _replaced_nodes = NULL;
> +}
> 
> I don't see cleanup of ReplacedNodes in Node::destruct() and other places where we clean up expensive nodes, for example.
> 
> Is the code in Parse::create_entry_map() correct? First, you destroy ReplacedNodes:
> 
>  _caller->map()->delete_replaced_nodes();
> 
> then you used it to initialize new map:
> 
>  SafePointNode* inmap = _caller->map();
>  map()->transfer_replaced_nodes_from(inmap, _new_idx);
> 
> 
> Thanks,
> Vladimir
> 
> On 5/19/14 4:37 AM, Roland Westrelin wrote:
>> I forgot the webrev:
>> 
>> http://cr.openjdk.java.net/~roland/8026796/webrev.00/
>> 
>> Roland.
>> 
>> On May 19, 2014, at 1:01 PM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
>> 
>>> This change reverts:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8024069
>>> 
>>> and propagates replacements in replace_in_map() to callers in a generic way. Every time replace_in_map() is called, the pair of nodes passed to replace_in_map is pushed on a list that the current map carries. When control flow paths merge, the lists for each of the control flow path?s maps are also merged. When parsing exits a method to return to a caller, the replaced nodes on the exit path are used to update the caller's map. This change also propagates replaced nodes after late inlining.
>>> 
>>> Roland.
>> 


From rasbold at google.com  Tue May 20 22:34:46 2014
From: rasbold at google.com (Chuck Rasbold)
Date: Tue, 20 May 2014 15:34:46 -0700
Subject: RFR(S): 8043354: Make is_return_allocated() respect allocated objects
	than can method-escape
Message-ID: <CALFb4KvDePz23cUbT+oqRgeQ6xNxyB6gqwOxc8wSpb6G+UG68A@mail.gmail.com>

This change forces bcEscapeAnalyzer to update the _allocated_escapes flag
if a var
escapes the method.

http://cr.openjdk.java.net/~rasbold/8043354/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140520/e7327a34/attachment.html>

From vladimir.kozlov at oracle.com  Wed May 21 01:12:11 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 20 May 2014 18:12:11 -0700
Subject: RFR(S): 8043354: Make is_return_allocated() respect allocated
	objects than can method-escape
In-Reply-To: <CALFb4KvDePz23cUbT+oqRgeQ6xNxyB6gqwOxc8wSpb6G+UG68A@mail.gmail.com>
References: <CALFb4KvDePz23cUbT+oqRgeQ6xNxyB6gqwOxc8wSpb6G+UG68A@mail.gmail.com>
Message-ID: <537BFD6B.2040402@oracle.com>

Thank you, Chuck, for the fix.

Changes look good, it was definitely missed. I am pushing it.

Thanks,
Vladimir

On 5/20/14 3:34 PM, Chuck Rasbold wrote:
> This change forces bcEscapeAnalyzer to update the _allocated_escapes
> flag if a var
> escapes the method.
>
> http://cr.openjdk.java.net/~rasbold/8043354/webrev.00/

From nils.eliasson at oracle.com  Wed May 21 09:40:35 2014
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Wed, 21 May 2014 11:40:35 +0200
Subject: RFR(S): 8031475: Missing oopmap in patching stubs
In-Reply-To: <5360F539.9090408@oracle.com>
References: <5360F539.9090408@oracle.com>
Message-ID: <537C7493.4050700@oracle.com>

Hi,

Thanks for the feedback. I found a piece of code that was supposed to 
make sure the oopmaps for patch stubs was correct but it only matched 
patching lir_moves. Since lir_checkcast and lir_moves need different 
checks for if they are patching I added a virtual method and replaced 
the earlier check.

Also removed a duplicate method and did a slight renaming for clarity.

http://cr.openjdk.java.net/~neliasso/8031475/webrev.06/

Thanks,
Nils

On 2014-04-30 15:06, Nils Eliasson wrote:
> Hi,
>
> I would like some feedback on this change from the c1 experts. It's 
> made in platform dependent code and will be added to the other 
> plattforms as well before submit.
>
> This change fixes a bug that has been observed in testing, and dug up 
> from a core file, but haven't reproduced standalone yet. When patching 
> for checkcast the oop we are casting is not kept in an oopmap during 
> the runtime patching call, a one time chance per run.
>
> The current change is for all the patching stub cases 
> (access_field_id, load_klass_id, load_mirror_id, load_appendix_id) - 
> is that needed? Do you see any potential for breaking anything? It is 
> difficult to trigger a GC at exact this point during a test.
>
> http://cr.openjdk.java.net/~neliasso/8031475/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8031475
>
> Thanks,
> Nils Eliasson
>
>
> Code example:
>
>   0x00007f20c943590c: mov    $0x718d65d38,%rdx  ;   {oop(a 
> 'BeanImpl2')}   // oops to be casted in rdx
>   0x00007f20c9435916: cmp    $0x0,%rdx
>   0x00007f20c943591a: je     0x00007f20c9435967   // jump to patching 
> stub
>   // patch location
>   0x00007f20c9435920: jmpq   0x00007f20c94359c5  ;   {no_reloc}
>   0x00007f20c9435925: add    %al,(%rax)
>   0x00007f20c9435927: add    %al,(%rax)
>   0x00007f20c9435929: add    %cl,-0x3eb7f786(%rbx)
>   0x00007f20c943592f: out    %eax,$0x3
>   // end of patch location
>   0x00007f20c9435931: cmp    %rbx,%rdi
>   0x00007f20c9435934: je     0x00007f20c9435967 // A dereference of 
> rdx somewhere here may crash if the oop has moved during a gc
>   0x00007f20c943593a: mov    0x10(%rbx),%esi
>   0x00007f20c943593d: cmp    (%rdi,%rsi,1),%rbx
>   0x00007f20c9435941: je     0x00007f20c9435967
>
>   ...
>
>   ;; PatchingStub slow case
>   ;;  patch template
>   0x00007f20c94359b6: mov    $0x0,%rbx          ; {metadata(NULL)}
>   ;; patch data encoded as movl
>   0x00007f20c94359c0: mov    $0xa050f00,%eax
>   ;; patch entry point
>   0x00007f20c94359c5: callq  0x00007f20c942e3e0  ; OopMap{[32]=Oop 
> off=266}   // rdx not live here, may safepoint on return from runtime 
> call
>                                                 ;*checkcast
>                                                 ; - 
> TestCheckCast::main at 25 (line 24)
>                                                 ;   {runtime_call}
>   0x00007f20c94359ca: jmpq   0x00007f20c9435920   // back to normal 
> control flow after patching
>


From roland.westrelin at oracle.com  Wed May 21 09:49:16 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 21 May 2014 11:49:16 +0200
Subject: RFR(S): 8031475: Missing oopmap in patching stubs
In-Reply-To: <537C7493.4050700@oracle.com>
References: <5360F539.9090408@oracle.com> <537C7493.4050700@oracle.com>
Message-ID: <4F37F16F-548B-421F-B9B1-EA4C7C1A7E9F@oracle.com>

> http://cr.openjdk.java.net/~neliasso/8031475/webrev.06/

That looks good to me.

Roland.

From filipp.zhinkin at oracle.com  Wed May 21 13:23:12 2014
From: filipp.zhinkin at oracle.com (Filipp Zhinkin)
Date: Wed, 21 May 2014 17:23:12 +0400
Subject: RFR (S): JDK-8038924: Test bit-instructions fails with unexpected
	exit value on sparc
In-Reply-To: <537270D4.9090400@oracle.com>
References: <53726935.90807@oracle.com> <537270D4.9090400@oracle.com>
Message-ID: <537CA8C0.2030200@oracle.com>

Vladimir,

sorry for a late response.

On 05/13/2014 11:21 PM, Vladimir Kozlov wrote:
> On 5/13/14 11:49 AM, Filipp Zhinkin wrote:
>> Hi all,
>>
>> please review fix forJDK-8038924.
>
> Filipp, please, provide the link to the bug report in you RFR.
https://bugs.openjdk.java.net/browse/JDK-8038924

Sorry for that, I'l take it in mind for future RFRs.
>
>>
>> CLI tests on BMI-related options previously took all externally passed
>> VM options,
>> add options that should be tested and launch new VM with such
>> combination of options.
>>
>> Unfortunately, some options like IgnoreUnrecognizedVMOptions, can affect
>> processing of tested flags and in such case tests fail.
>>
>> I've updated these tests so now they do not use externally passed 
>> options.
>
> I don't think it is right solution. Some external flags could be 
> important (DeoptimizeALot for example).
>
> You can add -XX:-IgnoreUnrecognizedVMOptions to tests which you expect 
> to fail (on platforms which does not have the feature). It will 
> nullify this flag passed from CL.
In general I agree with that point - tests should be able to use as much 
externally passed options as possible.
However, in this particular case I believe that it would be better to 
ignore such options, because these tests only launch a new VM with tests 
options and '-version' flag,
so we'll not be able to catch issues that we can't find with other BMI 
tests. And if CLI tests will not use externally passed options it will 
be easier to maintain it.

Note that other BMI-related tests use all externally passed options, so 
we can catch any issues related to JVM behaviour using it.

So I think that it will be better to avoid usage of externally passed 
options in CLI-tests and update compiler/intrinsics/bmi tests to run it 
on all platforms.

Thanks,
Filipp.
>
> Regards,
> Vladimir
>
>> Also, I've fix silly issue with String::format in
>> BMICommandLineOptionTestBase.java.
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.00/
>> Testing: manual and automated.
>>
>> Thanks,
>> Filipp.


From staffan.larsen at oracle.com  Wed May 21 13:44:32 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 21 May 2014 15:44:32 +0200
Subject: RFR: 8043637 compiler/ciReplay/TestSA.sh: java.lang.InternalError:
	missing reason for 17
Message-ID: <D114AE76-50D5-4BF5-A0B7-73FA8430AA13@oracle.com>

Please review this fix for a problem with compiler/ciReplay/TestSA.sh. It fails with an exception because SA can?t find the values for some the enum entries in Deoptimization::DeoptReason since they are missing from vmStructs.cpp. The patch below adds them.

bug: https://bugs.openjdk.java.net/browse/JDK-8043637

Thanks,
/Staffan


diff --git a/src/share/vm/runtime/vmStructs.cpp b/src/share/vm/runtime/vmStructs.cpp
--- a/src/share/vm/runtime/vmStructs.cpp
+++ b/src/share/vm/runtime/vmStructs.cpp
@@ -2498,6 +2498,9 @@
   declare_constant(Deoptimization::Reason_age)                            \
   declare_constant(Deoptimization::Reason_predicate)                      \
   declare_constant(Deoptimization::Reason_loop_limit_check)               \
+  declare_constant(Deoptimization::Reason_speculate_class_check)          \
+  declare_constant(Deoptimization::Reason_speculate_null_check)           \
+  declare_constant(Deoptimization::Reason_rtm_state_change)               \
   declare_constant(Deoptimization::Reason_LIMIT)                          \
   declare_constant(Deoptimization::Reason_RECORDED_LIMIT)                 \
                                                                           \

From roland.westrelin at oracle.com  Wed May 21 14:22:45 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 21 May 2014 16:22:45 +0200
Subject: RFR(S): 8043638: Multiple compilation attempts break LogCompulation,
	lead to confusing PrintInlining output
Message-ID: <88C17474-AA34-4A67-906E-9016768EC3A9@oracle.com>

When C2 attempts the compilation of a method multiple times:

1) the PrintInlining output shows inlining decisions for all attempts together (if compilation failure happens late in the compilation process)
2) the log of the multiple attempts confuses the LogCompilation tool.

http://cr.openjdk.java.net/~roland/8043638/webrev.00/

Roland.

From kirill.shirokov at oracle.com  Wed May 21 14:28:22 2014
From: kirill.shirokov at oracle.com (Kirill Shirokov)
Date: Wed, 21 May 2014 18:28:22 +0400
Subject: Request for review: JDK-8032970: stack size check methods for
	WhiteBox API
In-Reply-To: <5373BC61.4060700@oracle.com>
References: <52F0F609.3000108@oracle.com> <52F0FC77.709@oracle.com>
	<52F12B6B.1000303@oracle.com> <537399D5.5040807@Oracle.COM>
	<5373BC61.4060700@oracle.com>
Message-ID: <537CB806.6080909@oracle.com>

Hi Vladimir,

Thanks for reviewing. Please see the fixed diff:
http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.04/

I verified it with -Xint, -Xcomp and -Xmixed on all platforms (32- and 
64-bit).

Best regards,
Kirill

5/14/2014 10:56 PM, Vladimir Kozlov ?????:
> Thank you explanation, Kirill
>
> WBStackSize.java: please, use more descriptive names for variables:
>
> fss < tss * 0.9 || fss > tss
>
> You may want to run WBStackSize with -Xint. With compiled code stack 
> consumption is different. jtreg test could be run with -Xcomp by 
> harness (during Nightly), please, test such configurations.
>
> Thanks,
> Vladimir
>
> On 5/14/14 9:29 AM, Kirill Shirokov wrote:
>> Thanks to all reviewers!
>>
>> Could I ask to reivew the fixed patch:
>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.03/
>>
>> Bug report:
>> https://bugs.openjdk.java.net/browse/JDK-8032970
>>
>> The new functions will be used in the existing JSR292 tests -- we see a
>> lot of failures due to StackOverflowError.
>>
>> Best regards,
>> Kirill
>>
>> On 02/04/2014 10:03 PM, Vladimir Kozlov wrote:
>>> Kirill,
>>>
>>> You should include link to the bug report and add more explanation
>>> what this changes for. Will new functions be used in new or existing
>>> jsr292 tests?
>>>
>>> test/testlibrary_tests directory is used for classes used by other
>>> tests. I think you need to move new test WBStackSize.java into
>>> test/runtime directory.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 2/4/14 6:43 AM, Kirill Shirokov wrote:
>>>> Hi,
>>>>
>>>> Please review following webrev, which adds stack size checking methods
>>>> to WhiteBox API:
>>>>
>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.00/>
>>>>
>>>> Thank you,
>>>> Kirill
>>>>
>>>>
>>>>
>>


From markus.gronlund at oracle.com  Wed May 21 16:26:19 2014
From: markus.gronlund at oracle.com (=?iso-8859-1?B?TWFya3VzIEdy9m5sdW5k?=)
Date: Wed, 21 May 2014 09:26:19 -0700 (PDT)
Subject: RFR: 8043637 compiler/ciReplay/TestSA.sh:
	java.lang.InternalError: missing reason for 17
In-Reply-To: <D114AE76-50D5-4BF5-A0B7-73FA8430AA13@oracle.com>
References: <D114AE76-50D5-4BF5-A0B7-73FA8430AA13@oracle.com>
Message-ID: <fcf7714c-f8db-40f6-95e2-f3e8fd08441e@default>

Looks good.

/Markus

-----Original Message-----
From: Staffan Larsen 
Sent: den 21 maj 2014 15:45
To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net compiler
Subject: RFR: 8043637 compiler/ciReplay/TestSA.sh: java.lang.InternalError: missing reason for 17

Please review this fix for a problem with compiler/ciReplay/TestSA.sh. It fails with an exception because SA can't find the values for some the enum entries in Deoptimization::DeoptReason since they are missing from vmStructs.cpp. The patch below adds them.

bug: https://bugs.openjdk.java.net/browse/JDK-8043637

Thanks,
/Staffan


diff --git a/src/share/vm/runtime/vmStructs.cpp b/src/share/vm/runtime/vmStructs.cpp
--- a/src/share/vm/runtime/vmStructs.cpp
+++ b/src/share/vm/runtime/vmStructs.cpp
@@ -2498,6 +2498,9 @@
   declare_constant(Deoptimization::Reason_age)                            \
   declare_constant(Deoptimization::Reason_predicate)                      \
   declare_constant(Deoptimization::Reason_loop_limit_check)               \
+  declare_constant(Deoptimization::Reason_speculate_class_check)          \
+  declare_constant(Deoptimization::Reason_speculate_null_check)           \
+  declare_constant(Deoptimization::Reason_rtm_state_change)               \
   declare_constant(Deoptimization::Reason_LIMIT)                          \
   declare_constant(Deoptimization::Reason_RECORDED_LIMIT)                 \
                                                                           \

From roland.westrelin at oracle.com  Wed May 21 16:32:02 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 21 May 2014 18:32:02 +0200
Subject: RFR: 8043637 compiler/ciReplay/TestSA.sh:
	java.lang.InternalError: missing reason for 17
In-Reply-To: <D114AE76-50D5-4BF5-A0B7-73FA8430AA13@oracle.com>
References: <D114AE76-50D5-4BF5-A0B7-73FA8430AA13@oracle.com>
Message-ID: <08BBBFAD-B8AB-4618-BA8E-C03F4EF9F210@oracle.com>

Hi Staffan,

> Please review this fix for a problem with compiler/ciReplay/TestSA.sh. It fails with an exception because SA can?t find the values for some the enum entries in Deoptimization::DeoptReason since they are missing from vmStructs.cpp. The patch below adds them.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8043637

This is already fixed in hotspot-comp AFAICT.

Roland.

> 
> Thanks,
> /Staffan
> 
> 
> diff --git a/src/share/vm/runtime/vmStructs.cpp b/src/share/vm/runtime/vmStructs.cpp
> --- a/src/share/vm/runtime/vmStructs.cpp
> +++ b/src/share/vm/runtime/vmStructs.cpp
> @@ -2498,6 +2498,9 @@
>   declare_constant(Deoptimization::Reason_age)                            \
>   declare_constant(Deoptimization::Reason_predicate)                      \
>   declare_constant(Deoptimization::Reason_loop_limit_check)               \
> +  declare_constant(Deoptimization::Reason_speculate_class_check)          \
> +  declare_constant(Deoptimization::Reason_speculate_null_check)           \
> +  declare_constant(Deoptimization::Reason_rtm_state_change)               \
>   declare_constant(Deoptimization::Reason_LIMIT)                          \
>   declare_constant(Deoptimization::Reason_RECORDED_LIMIT)                 \
>                                                                           \


From christian.thalinger at oracle.com  Wed May 21 16:39:52 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 21 May 2014 09:39:52 -0700
Subject: RFR(S): 8031475: Missing oopmap in patching stubs
In-Reply-To: <537C7493.4050700@oracle.com>
References: <5360F539.9090408@oracle.com> <537C7493.4050700@oracle.com>
Message-ID: <B8D962F5-EE15-4358-9D53-707B1A653C48@oracle.com>

Yes, that looks good.

On May 21, 2014, at 2:40 AM, Nils Eliasson <nils.eliasson at oracle.com> wrote:

> Hi,
> 
> Thanks for the feedback. I found a piece of code that was supposed to make sure the oopmaps for patch stubs was correct but it only matched patching lir_moves. Since lir_checkcast and lir_moves need different checks for if they are patching I added a virtual method and replaced the earlier check.
> 
> Also removed a duplicate method and did a slight renaming for clarity.
> 
> http://cr.openjdk.java.net/~neliasso/8031475/webrev.06/
> 
> Thanks,
> Nils
> 
> On 2014-04-30 15:06, Nils Eliasson wrote:
>> Hi,
>> 
>> I would like some feedback on this change from the c1 experts. It's made in platform dependent code and will be added to the other plattforms as well before submit.
>> 
>> This change fixes a bug that has been observed in testing, and dug up from a core file, but haven't reproduced standalone yet. When patching for checkcast the oop we are casting is not kept in an oopmap during the runtime patching call, a one time chance per run.
>> 
>> The current change is for all the patching stub cases (access_field_id, load_klass_id, load_mirror_id, load_appendix_id) - is that needed? Do you see any potential for breaking anything? It is difficult to trigger a GC at exact this point during a test.
>> 
>> http://cr.openjdk.java.net/~neliasso/8031475/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8031475
>> 
>> Thanks,
>> Nils Eliasson
>> 
>> 
>> Code example:
>> 
>>  0x00007f20c943590c: mov    $0x718d65d38,%rdx  ;   {oop(a 'BeanImpl2')}   // oops to be casted in rdx
>>  0x00007f20c9435916: cmp    $0x0,%rdx
>>  0x00007f20c943591a: je     0x00007f20c9435967   // jump to patching stub
>>  // patch location
>>  0x00007f20c9435920: jmpq   0x00007f20c94359c5  ;   {no_reloc}
>>  0x00007f20c9435925: add    %al,(%rax)
>>  0x00007f20c9435927: add    %al,(%rax)
>>  0x00007f20c9435929: add    %cl,-0x3eb7f786(%rbx)
>>  0x00007f20c943592f: out    %eax,$0x3
>>  // end of patch location
>>  0x00007f20c9435931: cmp    %rbx,%rdi
>>  0x00007f20c9435934: je     0x00007f20c9435967 // A dereference of rdx somewhere here may crash if the oop has moved during a gc
>>  0x00007f20c943593a: mov    0x10(%rbx),%esi
>>  0x00007f20c943593d: cmp    (%rdi,%rsi,1),%rbx
>>  0x00007f20c9435941: je     0x00007f20c9435967
>> 
>>  ...
>> 
>>  ;; PatchingStub slow case
>>  ;;  patch template
>>  0x00007f20c94359b6: mov    $0x0,%rbx          ; {metadata(NULL)}
>>  ;; patch data encoded as movl
>>  0x00007f20c94359c0: mov    $0xa050f00,%eax
>>  ;; patch entry point
>>  0x00007f20c94359c5: callq  0x00007f20c942e3e0  ; OopMap{[32]=Oop off=266}   // rdx not live here, may safepoint on return from runtime call
>>                                                ;*checkcast
>>                                                ; - TestCheckCast::main at 25 (line 24)
>>                                                ;   {runtime_call}
>>  0x00007f20c94359ca: jmpq   0x00007f20c9435920   // back to normal control flow after patching
>> 
> 


From christian.thalinger at oracle.com  Wed May 21 17:04:52 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 21 May 2014 10:04:52 -0700
Subject: Request for review: JDK-8032970: stack size check methods for
	WhiteBox API
In-Reply-To: <537CB806.6080909@oracle.com>
References: <52F0F609.3000108@oracle.com> <52F0FC77.709@oracle.com>
	<52F12B6B.1000303@oracle.com> <537399D5.5040807@Oracle.COM>
	<5373BC61.4060700@oracle.com> <537CB806.6080909@oracle.com>
Message-ID: <1886B65C-AFA0-4B93-832C-31E605BA3F5F@oracle.com>

Quick question:  why is is called WB_GetThreadFullStackSize?  What defines ?full??

On May 21, 2014, at 7:28 AM, Kirill Shirokov <kirill.shirokov at oracle.com> wrote:

> Hi Vladimir,
> 
> Thanks for reviewing. Please see the fixed diff:
> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.04/
> 
> I verified it with -Xint, -Xcomp and -Xmixed on all platforms (32- and 64-bit).
> 
> Best regards,
> Kirill
> 
> 5/14/2014 10:56 PM, Vladimir Kozlov ?????:
>> Thank you explanation, Kirill
>> 
>> WBStackSize.java: please, use more descriptive names for variables:
>> 
>> fss < tss * 0.9 || fss > tss
>> 
>> You may want to run WBStackSize with -Xint. With compiled code stack consumption is different. jtreg test could be run with -Xcomp by harness (during Nightly), please, test such configurations.
>> 
>> Thanks,
>> Vladimir
>> 
>> On 5/14/14 9:29 AM, Kirill Shirokov wrote:
>>> Thanks to all reviewers!
>>> 
>>> Could I ask to reivew the fixed patch:
>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.03/
>>> 
>>> Bug report:
>>> https://bugs.openjdk.java.net/browse/JDK-8032970
>>> 
>>> The new functions will be used in the existing JSR292 tests -- we see a
>>> lot of failures due to StackOverflowError.
>>> 
>>> Best regards,
>>> Kirill
>>> 
>>> On 02/04/2014 10:03 PM, Vladimir Kozlov wrote:
>>>> Kirill,
>>>> 
>>>> You should include link to the bug report and add more explanation
>>>> what this changes for. Will new functions be used in new or existing
>>>> jsr292 tests?
>>>> 
>>>> test/testlibrary_tests directory is used for classes used by other
>>>> tests. I think you need to move new test WBStackSize.java into
>>>> test/runtime directory.
>>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>> On 2/4/14 6:43 AM, Kirill Shirokov wrote:
>>>>> Hi,
>>>>> 
>>>>> Please review following webrev, which adds stack size checking methods
>>>>> to WhiteBox API:
>>>>> 
>>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.00/
>>>>> <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.00/>
>>>>> 
>>>>> Thank you,
>>>>> Kirill
>>>>> 
>>>>> 
>>>>> 
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140521/8c65ce73/attachment.html>

From vladimir.kozlov at oracle.com  Wed May 21 17:50:50 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 21 May 2014 10:50:50 -0700
Subject: Request for review: JDK-8032970: stack size check methods for
	WhiteBox API
In-Reply-To: <537CB806.6080909@oracle.com>
References: <52F0F609.3000108@oracle.com> <52F0FC77.709@oracle.com>
	<52F12B6B.1000303@oracle.com> <537399D5.5040807@Oracle.COM>
	<5373BC61.4060700@oracle.com> <537CB806.6080909@oracle.com>
Message-ID: <537CE77A.6030000@oracle.com>

Looks good.

Vladimir

On 5/21/14 7:28 AM, Kirill Shirokov wrote:
> Hi Vladimir,
>
> Thanks for reviewing. Please see the fixed diff:
> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.04/
>
> I verified it with -Xint, -Xcomp and -Xmixed on all platforms (32- and
> 64-bit).
>
> Best regards,
> Kirill
>
> 5/14/2014 10:56 PM, Vladimir Kozlov ?????:
>> Thank you explanation, Kirill
>>
>> WBStackSize.java: please, use more descriptive names for variables:
>>
>> fss < tss * 0.9 || fss > tss
>>
>> You may want to run WBStackSize with -Xint. With compiled code stack
>> consumption is different. jtreg test could be run with -Xcomp by
>> harness (during Nightly), please, test such configurations.
>>
>> Thanks,
>> Vladimir
>>
>> On 5/14/14 9:29 AM, Kirill Shirokov wrote:
>>> Thanks to all reviewers!
>>>
>>> Could I ask to reivew the fixed patch:
>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.03/
>>>
>>> Bug report:
>>> https://bugs.openjdk.java.net/browse/JDK-8032970
>>>
>>> The new functions will be used in the existing JSR292 tests -- we see a
>>> lot of failures due to StackOverflowError.
>>>
>>> Best regards,
>>> Kirill
>>>
>>> On 02/04/2014 10:03 PM, Vladimir Kozlov wrote:
>>>> Kirill,
>>>>
>>>> You should include link to the bug report and add more explanation
>>>> what this changes for. Will new functions be used in new or existing
>>>> jsr292 tests?
>>>>
>>>> test/testlibrary_tests directory is used for classes used by other
>>>> tests. I think you need to move new test WBStackSize.java into
>>>> test/runtime directory.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 2/4/14 6:43 AM, Kirill Shirokov wrote:
>>>>> Hi,
>>>>>
>>>>> Please review following webrev, which adds stack size checking methods
>>>>> to WhiteBox API:
>>>>>
>>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.00/
>>>>> <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.00/>
>>>>>
>>>>> Thank you,
>>>>> Kirill
>>>>>
>>>>>
>>>>>
>>>
>

From vladimir.kozlov at oracle.com  Wed May 21 18:08:40 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 21 May 2014 11:08:40 -0700
Subject: RFR(S): 8043638: Multiple compilation attempts break
	LogCompulation, lead to confusing PrintInlining output
In-Reply-To: <88C17474-AA34-4A67-906E-9016768EC3A9@oracle.com>
References: <88C17474-AA34-4A67-906E-9016768EC3A9@oracle.com>
Message-ID: <537CEBA8.1030505@oracle.com>

Looks good.

Vladimir

On 5/21/14 7:22 AM, Roland Westrelin wrote:
> When C2 attempts the compilation of a method multiple times:
>
> 1) the PrintInlining output shows inlining decisions for all attempts together (if compilation failure happens late in the compilation process)
> 2) the log of the multiple attempts confuses the LogCompilation tool.
>
> http://cr.openjdk.java.net/~roland/8043638/webrev.00/
>
> Roland.
>

From staffan.larsen at oracle.com  Wed May 21 18:11:48 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 21 May 2014 20:11:48 +0200
Subject: RFR: 8043637 compiler/ciReplay/TestSA.sh:
	java.lang.InternalError: missing reason for 17
In-Reply-To: <08BBBFAD-B8AB-4618-BA8E-C03F4EF9F210@oracle.com>
References: <D114AE76-50D5-4BF5-A0B7-73FA8430AA13@oracle.com>
	<08BBBFAD-B8AB-4618-BA8E-C03F4EF9F210@oracle.com>
Message-ID: <F6612645-DC8C-499F-985D-EAAD2A76B9FB@oracle.com>

Great! I?ll close my bug as a dup of 8026694.

/Staffan

On 21 maj 2014, at 18:32, Roland Westrelin <roland.westrelin at oracle.com> wrote:

> Hi Staffan,
> 
>> Please review this fix for a problem with compiler/ciReplay/TestSA.sh. It fails with an exception because SA can?t find the values for some the enum entries in Deoptimization::DeoptReason since they are missing from vmStructs.cpp. The patch below adds them.
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8043637
> 
> This is already fixed in hotspot-comp AFAICT.
> 
> Roland.
> 
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> diff --git a/src/share/vm/runtime/vmStructs.cpp b/src/share/vm/runtime/vmStructs.cpp
>> --- a/src/share/vm/runtime/vmStructs.cpp
>> +++ b/src/share/vm/runtime/vmStructs.cpp
>> @@ -2498,6 +2498,9 @@
>>  declare_constant(Deoptimization::Reason_age)                            \
>>  declare_constant(Deoptimization::Reason_predicate)                      \
>>  declare_constant(Deoptimization::Reason_loop_limit_check)               \
>> +  declare_constant(Deoptimization::Reason_speculate_class_check)          \
>> +  declare_constant(Deoptimization::Reason_speculate_null_check)           \
>> +  declare_constant(Deoptimization::Reason_rtm_state_change)               \
>>  declare_constant(Deoptimization::Reason_LIMIT)                          \
>>  declare_constant(Deoptimization::Reason_RECORDED_LIMIT)                 \
>>                                                                          \
> 


From vladimir.kozlov at oracle.com  Wed May 21 18:17:57 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 21 May 2014 11:17:57 -0700
Subject: RFR (S): JDK-8038924: Test bit-instructions fails with unexpected
	exit value on sparc
In-Reply-To: <537CA8C0.2030200@oracle.com>
References: <53726935.90807@oracle.com> <537270D4.9090400@oracle.com>
	<537CA8C0.2030200@oracle.com>
Message-ID: <537CEDD5.9070406@oracle.com>

Not surprisingly :) I missed that it runs only with -version. It is hard 
to see which options are used. Non of these tests list '-version' even 
in a comment.

I agree that if you fork the same VM (server or client, 32-bit or 
64-bit) and run it with -version flag you don't need to pass all CL options.

Thanks,
Vladimir

On 5/21/14 6:23 AM, Filipp Zhinkin wrote:
> Vladimir,
>
> sorry for a late response.
>
> On 05/13/2014 11:21 PM, Vladimir Kozlov wrote:
>> On 5/13/14 11:49 AM, Filipp Zhinkin wrote:
>>> Hi all,
>>>
>>> please review fix forJDK-8038924.
>>
>> Filipp, please, provide the link to the bug report in you RFR.
> https://bugs.openjdk.java.net/browse/JDK-8038924
>
> Sorry for that, I'l take it in mind for future RFRs.
>>
>>>
>>> CLI tests on BMI-related options previously took all externally passed
>>> VM options,
>>> add options that should be tested and launch new VM with such
>>> combination of options.
>>>
>>> Unfortunately, some options like IgnoreUnrecognizedVMOptions, can affect
>>> processing of tested flags and in such case tests fail.
>>>
>>> I've updated these tests so now they do not use externally passed
>>> options.
>>
>> I don't think it is right solution. Some external flags could be
>> important (DeoptimizeALot for example).
>>
>> You can add -XX:-IgnoreUnrecognizedVMOptions to tests which you expect
>> to fail (on platforms which does not have the feature). It will
>> nullify this flag passed from CL.
> In general I agree with that point - tests should be able to use as much
> externally passed options as possible.
> However, in this particular case I believe that it would be better to
> ignore such options, because these tests only launch a new VM with tests
> options and '-version' flag,
> so we'll not be able to catch issues that we can't find with other BMI
> tests. And if CLI tests will not use externally passed options it will
> be easier to maintain it.
>
> Note that other BMI-related tests use all externally passed options, so
> we can catch any issues related to JVM behaviour using it.
>
> So I think that it will be better to avoid usage of externally passed
> options in CLI-tests and update compiler/intrinsics/bmi tests to run it
> on all platforms.
>
> Thanks,
> Filipp.
>>
>> Regards,
>> Vladimir
>>
>>> Also, I've fix silly issue with String::format in
>>> BMICommandLineOptionTestBase.java.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.00/
>>> Testing: manual and automated.
>>>
>>> Thanks,
>>> Filipp.
>

From filipp.zhinkin at oracle.com  Thu May 22 18:29:17 2014
From: filipp.zhinkin at oracle.com (Filipp Zhinkin)
Date: Thu, 22 May 2014 22:29:17 +0400
Subject: RFR (S): JDK-8038924: Test bit-instructions fails with unexpected
	exit value on sparc
In-Reply-To: <537CEDD5.9070406@oracle.com>
References: <53726935.90807@oracle.com> <537270D4.9090400@oracle.com>
	<537CA8C0.2030200@oracle.com> <537CEDD5.9070406@oracle.com>
Message-ID: <537E41FD.1090905@oracle.com>

Vladimir,

so you're OK with this change?

I've filed an RFE https://bugs.openjdk.java.net/browse/JDK-8043674 for 
allowing execution of correctness tests on all platforms.

Thanks,
Filipp.

On 05/21/2014 10:17 PM, Vladimir Kozlov wrote:
> Not surprisingly :) I missed that it runs only with -version. It is 
> hard to see which options are used. Non of these tests list '-version' 
> even in a comment.
>
> I agree that if you fork the same VM (server or client, 32-bit or 
> 64-bit) and run it with -version flag you don't need to pass all CL 
> options.
>
> Thanks,
> Vladimir
>
> On 5/21/14 6:23 AM, Filipp Zhinkin wrote:
>> Vladimir,
>>
>> sorry for a late response.
>>
>> On 05/13/2014 11:21 PM, Vladimir Kozlov wrote:
>>> On 5/13/14 11:49 AM, Filipp Zhinkin wrote:
>>>> Hi all,
>>>>
>>>> please review fix forJDK-8038924.
>>>
>>> Filipp, please, provide the link to the bug report in you RFR.
>> https://bugs.openjdk.java.net/browse/JDK-8038924
>>
>> Sorry for that, I'l take it in mind for future RFRs.
>>>
>>>>
>>>> CLI tests on BMI-related options previously took all externally passed
>>>> VM options,
>>>> add options that should be tested and launch new VM with such
>>>> combination of options.
>>>>
>>>> Unfortunately, some options like IgnoreUnrecognizedVMOptions, can 
>>>> affect
>>>> processing of tested flags and in such case tests fail.
>>>>
>>>> I've updated these tests so now they do not use externally passed
>>>> options.
>>>
>>> I don't think it is right solution. Some external flags could be
>>> important (DeoptimizeALot for example).
>>>
>>> You can add -XX:-IgnoreUnrecognizedVMOptions to tests which you expect
>>> to fail (on platforms which does not have the feature). It will
>>> nullify this flag passed from CL.
>> In general I agree with that point - tests should be able to use as much
>> externally passed options as possible.
>> However, in this particular case I believe that it would be better to
>> ignore such options, because these tests only launch a new VM with tests
>> options and '-version' flag,
>> so we'll not be able to catch issues that we can't find with other BMI
>> tests. And if CLI tests will not use externally passed options it will
>> be easier to maintain it.
>>
>> Note that other BMI-related tests use all externally passed options, so
>> we can catch any issues related to JVM behaviour using it.
>>
>> So I think that it will be better to avoid usage of externally passed
>> options in CLI-tests and update compiler/intrinsics/bmi tests to run it
>> on all platforms.
>>
>> Thanks,
>> Filipp.
>>>
>>> Regards,
>>> Vladimir
>>>
>>>> Also, I've fix silly issue with String::format in
>>>> BMICommandLineOptionTestBase.java.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.00/
>>>> Testing: manual and automated.
>>>>
>>>> Thanks,
>>>> Filipp.
>>


From vladimir.kozlov at oracle.com  Wed May 21 18:40:34 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 21 May 2014 11:40:34 -0700
Subject: RFR (S): JDK-8038924: Test bit-instructions fails with unexpected
	exit value on sparc
In-Reply-To: <537E41FD.1090905@oracle.com>
References: <53726935.90807@oracle.com> <537270D4.9090400@oracle.com>
	<537CA8C0.2030200@oracle.com> <537CEDD5.9070406@oracle.com>
	<537E41FD.1090905@oracle.com>
Message-ID: <537CF322.7040507@oracle.com>

I am okay with changes. I would only suggest to add comment in tests to 
list what command line will be used when forked VM is executed.

thanks,
Vladimir

On 5/22/14 11:29 AM, Filipp Zhinkin wrote:
> Vladimir,
>
> so you're OK with this change?
>
> I've filed an RFE https://bugs.openjdk.java.net/browse/JDK-8043674 for
> allowing execution of correctness tests on all platforms.
>
> Thanks,
> Filipp.
>
> On 05/21/2014 10:17 PM, Vladimir Kozlov wrote:
>> Not surprisingly :) I missed that it runs only with -version. It is
>> hard to see which options are used. Non of these tests list '-version'
>> even in a comment.
>>
>> I agree that if you fork the same VM (server or client, 32-bit or
>> 64-bit) and run it with -version flag you don't need to pass all CL
>> options.
>>
>> Thanks,
>> Vladimir
>>
>> On 5/21/14 6:23 AM, Filipp Zhinkin wrote:
>>> Vladimir,
>>>
>>> sorry for a late response.
>>>
>>> On 05/13/2014 11:21 PM, Vladimir Kozlov wrote:
>>>> On 5/13/14 11:49 AM, Filipp Zhinkin wrote:
>>>>> Hi all,
>>>>>
>>>>> please review fix forJDK-8038924.
>>>>
>>>> Filipp, please, provide the link to the bug report in you RFR.
>>> https://bugs.openjdk.java.net/browse/JDK-8038924
>>>
>>> Sorry for that, I'l take it in mind for future RFRs.
>>>>
>>>>>
>>>>> CLI tests on BMI-related options previously took all externally passed
>>>>> VM options,
>>>>> add options that should be tested and launch new VM with such
>>>>> combination of options.
>>>>>
>>>>> Unfortunately, some options like IgnoreUnrecognizedVMOptions, can
>>>>> affect
>>>>> processing of tested flags and in such case tests fail.
>>>>>
>>>>> I've updated these tests so now they do not use externally passed
>>>>> options.
>>>>
>>>> I don't think it is right solution. Some external flags could be
>>>> important (DeoptimizeALot for example).
>>>>
>>>> You can add -XX:-IgnoreUnrecognizedVMOptions to tests which you expect
>>>> to fail (on platforms which does not have the feature). It will
>>>> nullify this flag passed from CL.
>>> In general I agree with that point - tests should be able to use as much
>>> externally passed options as possible.
>>> However, in this particular case I believe that it would be better to
>>> ignore such options, because these tests only launch a new VM with tests
>>> options and '-version' flag,
>>> so we'll not be able to catch issues that we can't find with other BMI
>>> tests. And if CLI tests will not use externally passed options it will
>>> be easier to maintain it.
>>>
>>> Note that other BMI-related tests use all externally passed options, so
>>> we can catch any issues related to JVM behaviour using it.
>>>
>>> So I think that it will be better to avoid usage of externally passed
>>> options in CLI-tests and update compiler/intrinsics/bmi tests to run it
>>> on all platforms.
>>>
>>> Thanks,
>>> Filipp.
>>>>
>>>> Regards,
>>>> Vladimir
>>>>
>>>>> Also, I've fix silly issue with String::format in
>>>>> BMICommandLineOptionTestBase.java.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.00/
>>>>> Testing: manual and automated.
>>>>>
>>>>> Thanks,
>>>>> Filipp.
>>>
>

From vladimir.kozlov at oracle.com  Wed May 21 19:11:24 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 21 May 2014 12:11:24 -0700
Subject: RFR (XS) 8043274: Test compiler/7184394/TestAESMain.java gets NPE
	on solaris
Message-ID: <537CFA5C.2000902@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8043274
http://cr.openjdk.java.net/~kvn/8043274/webrev/

Contributed by Shrinivas:

"Current code destroys value in L0 before registers are saved.
I tested this change with and without compressed oops using the test 
case that was initially contributed as part of JDK-7184394. I tested all 
key sizes, with few different input sizes and both aligned and 
mis-aligned cases. JTREG jdk tests in com/sun/crypto/provider/ did not 
show any new failures. JPRT run was also successful."

The fix looks good and I will push it.

Thanks,
Vladimir


From kirill.shirokov at oracle.com  Wed May 21 20:57:24 2014
From: kirill.shirokov at oracle.com (Kirill Shirokov)
Date: Thu, 22 May 2014 00:57:24 +0400
Subject: Request for review: JDK-8032970: stack size check methods for
	WhiteBox API
In-Reply-To: <1886B65C-AFA0-4B93-832C-31E605BA3F5F@oracle.com>
References: <52F0F609.3000108@oracle.com> <52F0FC77.709@oracle.com>
	<52F12B6B.1000303@oracle.com> <537399D5.5040807@Oracle.COM>
	<5373BC61.4060700@oracle.com> <537CB806.6080909@oracle.com>
	<1886B65C-AFA0-4B93-832C-31E605BA3F5F@oracle.com>
Message-ID: <537D1334.1040504@oracle.com>

WB_GetThreadFullStackSize returns value of JavaThread::stack_size(). 
Full here is used to denote 'Full' vs. 'Remaining'.

5/21/2014 9:04 PM, Christian Thalinger ?????:
> Quick question:  why is is called *WB_GetThreadFullStackSize*?  What 
> defines ?full??
>
> On May 21, 2014, at 7:28 AM, Kirill Shirokov 
> <kirill.shirokov at oracle.com <mailto:kirill.shirokov at oracle.com>> wrote:
>
>> Hi Vladimir,
>>
>> Thanks for reviewing. Please see the fixed diff:
>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.04/ 
>> <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.04/>
>>
>> I verified it with -Xint, -Xcomp and -Xmixed on all platforms (32- 
>> and 64-bit).
>>
>> Best regards,
>> Kirill
>>
>> 5/14/2014 10:56 PM, Vladimir Kozlov ?????:
>>> Thank you explanation, Kirill
>>>
>>> WBStackSize.java: please, use more descriptive names for variables:
>>>
>>> fss < tss * 0.9 || fss > tss
>>>
>>> You may want to run WBStackSize with -Xint. With compiled code stack 
>>> consumption is different. jtreg test could be run with -Xcomp by 
>>> harness (during Nightly), please, test such configurations.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/14/14 9:29 AM, Kirill Shirokov wrote:
>>>> Thanks to all reviewers!
>>>>
>>>> Could I ask to reivew the fixed patch:
>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.03/
>>>>
>>>> Bug report:
>>>> https://bugs.openjdk.java.net/browse/JDK-8032970
>>>>
>>>> The new functions will be used in the existing JSR292 tests -- we see a
>>>> lot of failures due to StackOverflowError.
>>>>
>>>> Best regards,
>>>> Kirill
>>>>
>>>> On 02/04/2014 10:03 PM, Vladimir Kozlov wrote:
>>>>> Kirill,
>>>>>
>>>>> You should include link to the bug report and add more explanation
>>>>> what this changes for. Will new functions be used in new or existing
>>>>> jsr292 tests?
>>>>>
>>>>> test/testlibrary_tests directory is used for classes used by other
>>>>> tests. I think you need to move new test WBStackSize.java into
>>>>> test/runtime directory.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 2/4/14 6:43 AM, Kirill Shirokov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review following webrev, which adds stack size checking 
>>>>>> methods
>>>>>> to WhiteBox API:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.00/>
>>>>>>
>>>>>> Thank you,
>>>>>> Kirill
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140522/9e91937d/attachment.html>

From rasbold at google.com  Wed May 21 22:05:39 2014
From: rasbold at google.com (Chuck Rasbold)
Date: Wed, 21 May 2014 15:05:39 -0700
Subject: RFR(S): 8043354: Make is_return_allocated() respect allocated
	objects than can method-escape
In-Reply-To: <537BFD6B.2040402@oracle.com>
References: <CALFb4KvDePz23cUbT+oqRgeQ6xNxyB6gqwOxc8wSpb6G+UG68A@mail.gmail.com>
	<537BFD6B.2040402@oracle.com>
Message-ID: <CALFb4KuSZxvbs0B_WycR5AiASgViVd2A1xhNM=KhswT14Pf9hQ@mail.gmail.com>

Thanks, Vladimir!


On Tue, May 20, 2014 at 6:12 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> wrote:

> Thank you, Chuck, for the fix.
>
> Changes look good, it was definitely missed. I am pushing it.
>
> Thanks,
> Vladimir
>
>
> On 5/20/14 3:34 PM, Chuck Rasbold wrote:
>
>> This change forces bcEscapeAnalyzer to update the _allocated_escapes
>> flag if a var
>> escapes the method.
>>
>> http://cr.openjdk.java.net/~rasbold/8043354/webrev.00/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140521/ca971f0d/attachment.html>

From christian.thalinger at oracle.com  Wed May 21 22:52:46 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 21 May 2014 15:52:46 -0700
Subject: Request for review: JDK-8032970: stack size check methods for
	WhiteBox API
In-Reply-To: <537D1334.1040504@oracle.com>
References: <52F0F609.3000108@oracle.com> <52F0FC77.709@oracle.com>
	<52F12B6B.1000303@oracle.com> <537399D5.5040807@Oracle.COM>
	<5373BC61.4060700@oracle.com> <537CB806.6080909@oracle.com>
	<1886B65C-AFA0-4B93-832C-31E605BA3F5F@oracle.com>
	<537D1334.1040504@oracle.com>
Message-ID: <CF3032AB-BE9E-4A48-9EC1-2A2C4F89287A@oracle.com>

I?d prefer just WB_GetThreadStackSize.

On May 21, 2014, at 1:57 PM, Kirill Shirokov <kirill.shirokov at oracle.com> wrote:

> WB_GetThreadFullStackSize returns value of JavaThread::stack_size(). Full here is used to denote 'Full' vs. 'Remaining'.
> 
> 5/21/2014 9:04 PM, Christian Thalinger ?????:
>> Quick question:  why is is called WB_GetThreadFullStackSize?  What defines ?full??
>> 
>> On May 21, 2014, at 7:28 AM, Kirill Shirokov <kirill.shirokov at oracle.com> wrote:
>> 
>>> Hi Vladimir,
>>> 
>>> Thanks for reviewing. Please see the fixed diff:
>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.04/
>>> 
>>> I verified it with -Xint, -Xcomp and -Xmixed on all platforms (32- and 64-bit).
>>> 
>>> Best regards,
>>> Kirill
>>> 
>>> 5/14/2014 10:56 PM, Vladimir Kozlov ?????:
>>>> Thank you explanation, Kirill
>>>> 
>>>> WBStackSize.java: please, use more descriptive names for variables:
>>>> 
>>>> fss < tss * 0.9 || fss > tss
>>>> 
>>>> You may want to run WBStackSize with -Xint. With compiled code stack consumption is different. jtreg test could be run with -Xcomp by harness (during Nightly), please, test such configurations.
>>>> 
>>>> Thanks,
>>>> Vladimir
>>>> 
>>>> On 5/14/14 9:29 AM, Kirill Shirokov wrote:
>>>>> Thanks to all reviewers!
>>>>> 
>>>>> Could I ask to reivew the fixed patch:
>>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.03/
>>>>> 
>>>>> Bug report:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8032970
>>>>> 
>>>>> The new functions will be used in the existing JSR292 tests -- we see a
>>>>> lot of failures due to StackOverflowError.
>>>>> 
>>>>> Best regards,
>>>>> Kirill
>>>>> 
>>>>> On 02/04/2014 10:03 PM, Vladimir Kozlov wrote:
>>>>>> Kirill,
>>>>>> 
>>>>>> You should include link to the bug report and add more explanation
>>>>>> what this changes for. Will new functions be used in new or existing
>>>>>> jsr292 tests?
>>>>>> 
>>>>>> test/testlibrary_tests directory is used for classes used by other
>>>>>> tests. I think you need to move new test WBStackSize.java into
>>>>>> test/runtime directory.
>>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>> 
>>>>>> On 2/4/14 6:43 AM, Kirill Shirokov wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Please review following webrev, which adds stack size checking methods
>>>>>>> to WhiteBox API:
>>>>>>> 
>>>>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.00/
>>>>>>> <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.00/>
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> Kirill
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140521/8387698d/attachment-0001.html>

From rickard.backman at oracle.com  Thu May 22 11:53:47 2014
From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=)
Date: Thu, 22 May 2014 13:53:47 +0200
Subject: RFR(XS): 8030976: untaken paths should be more vigorously pruned at
	highest optimization level
Message-ID: <20140522115347.GE23239@rbackman>

Hi all,

can I please have reviews for this change.
The patch makes C2 place uncommon traps on previously untaken branches
much more aggressively (we are simply trusting the profiling more). 
This improves performance for a couple of different patterns.

Example:

class Test {
  public int[] array = new int[] = { 1, 1, 2, 3, 5, 8, 13 };

  public void some_method() {
    for (int i = 0; i < array.length; i++) {
      if (array[i] < 255) {
        some_call();
      } else {
        some_other_call();
      }
    }
  }
}

Where we previously if the else branch had never been taken rarely would
inline the some_other_call and when array escapes we can't make
assumptions on non-changing lengths, call killing registers, etc.

On some of the Nashorn benchmark this patch increases score by 35%,
others don't see any change at all. No difference on SpecJBB 2005.
More performance numbers / microbenchmark in the comments of the bug.

Webrev: http://cr.openjdk.java.net/~rbackman/8030976/
Bug: https://bugs.openjdk.java.net/browse/JDK-8030976

Thanks
/R
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140522/8a4ce882/signature.asc>

From rickard.backman at oracle.com  Thu May 22 13:46:00 2014
From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=)
Date: Thu, 22 May 2014 15:46:00 +0200
Subject: RFR(XS): 8030976: untaken paths should be more vigorously pruned
	at highest optimization level
In-Reply-To: <20140522115347.GE23239@rbackman>
References: <20140522115347.GE23239@rbackman>
Message-ID: <20140522134600.GF23239@rbackman>

Roland pointed out a problem with the Reason used. New webrev coming
shortly.

Thanks Roland.

On 05/22, Rickard B?ckman wrote:
> Hi all,
> 
> can I please have reviews for this change.
> The patch makes C2 place uncommon traps on previously untaken branches
> much more aggressively (we are simply trusting the profiling more). 
> This improves performance for a couple of different patterns.
> 
> Example:
> 
> class Test {
>   public int[] array = new int[] = { 1, 1, 2, 3, 5, 8, 13 };
> 
>   public void some_method() {
>     for (int i = 0; i < array.length; i++) {
>       if (array[i] < 255) {
>         some_call();
>       } else {
>         some_other_call();
>       }
>     }
>   }
> }
> 
> Where we previously if the else branch had never been taken rarely would
> inline the some_other_call and when array escapes we can't make
> assumptions on non-changing lengths, call killing registers, etc.
> 
> On some of the Nashorn benchmark this patch increases score by 35%,
> others don't see any change at all. No difference on SpecJBB 2005.
> More performance numbers / microbenchmark in the comments of the bug.
> 
> Webrev: http://cr.openjdk.java.net/~rbackman/8030976/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8030976
> 
> Thanks
> /R


/R
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140522/8bc3c5d9/signature.asc>

From christian.thalinger at oracle.com  Thu May 22 16:39:15 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 22 May 2014 09:39:15 -0700
Subject: RFR(XS): 8030976: untaken paths should be more vigorously pruned
	at highest optimization level
In-Reply-To: <20140522115347.GE23239@rbackman>
References: <20140522115347.GE23239@rbackman>
Message-ID: <B6F83BD5-8C15-4954-A35E-7D3A78A242EB@oracle.com>


On May 22, 2014, at 4:53 AM, Rickard B?ckman <rickard.backman at oracle.com> wrote:

> Hi all,
> 
> can I please have reviews for this change.
> The patch makes C2 place uncommon traps on previously untaken branches
> much more aggressively (we are simply trusting the profiling more). 
> This improves performance for a couple of different patterns.
> 
> Example:
> 
> class Test {
>  public int[] array = new int[] = { 1, 1, 2, 3, 5, 8, 13 };
> 
>  public void some_method() {
>    for (int i = 0; i < array.length; i++) {
>      if (array[i] < 255) {
>        some_call();
>      } else {
>        some_other_call();
>      }
>    }
>  }
> }
> 
> Where we previously if the else branch had never been taken rarely would
> inline the some_other_call and when array escapes we can't make
> assumptions on non-changing lengths, call killing registers, etc.
> 
> On some of the Nashorn benchmark this patch increases score by 35%,
> others don't see any change at all. No difference on SpecJBB 2005.
> More performance numbers / microbenchmark in the comments of the bug.

One comment says:

"Trying to get numbers from some bigger benchmarks as well.?

Did you only run SPECjbb2005 or others as well?

> 
> Webrev: http://cr.openjdk.java.net/~rbackman/8030976/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8030976
> 
> Thanks
> /R


From filipp.zhinkin at oracle.com  Thu May 22 17:46:12 2014
From: filipp.zhinkin at oracle.com (Filipp Zhinkin)
Date: Thu, 22 May 2014 21:46:12 +0400
Subject: RFR (S): JDK-8038924: Test bit-instructions fails with unexpected
	exit value on sparc
In-Reply-To: <537CF322.7040507@oracle.com>
References: <53726935.90807@oracle.com> <537270D4.9090400@oracle.com>
	<537CA8C0.2030200@oracle.com> <537CEDD5.9070406@oracle.com>
	<537E41FD.1090905@oracle.com> <537CF322.7040507@oracle.com>
Message-ID: <537E37E4.2030306@oracle.com>

Vladimir,

On 05/21/2014 10:40 PM, Vladimir Kozlov wrote:
> I am okay with changes. I would only suggest to add comment in tests 
> to list what command line will be used when forked VM is executed.
I agree, it will save a lot of time for everyone who need look at tests' 
sources.

Here is an updated webrev:
http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.01/

Thanks,
Filipp.
>
> thanks,
> Vladimir
>
> On 5/22/14 11:29 AM, Filipp Zhinkin wrote:
>> Vladimir,
>>
>> so you're OK with this change?
>>
>> I've filed an RFE https://bugs.openjdk.java.net/browse/JDK-8043674 for
>> allowing execution of correctness tests on all platforms.
>>
>> Thanks,
>> Filipp.
>>
>> On 05/21/2014 10:17 PM, Vladimir Kozlov wrote:
>>> Not surprisingly :) I missed that it runs only with -version. It is
>>> hard to see which options are used. Non of these tests list '-version'
>>> even in a comment.
>>>
>>> I agree that if you fork the same VM (server or client, 32-bit or
>>> 64-bit) and run it with -version flag you don't need to pass all CL
>>> options.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/21/14 6:23 AM, Filipp Zhinkin wrote:
>>>> Vladimir,
>>>>
>>>> sorry for a late response.
>>>>
>>>> On 05/13/2014 11:21 PM, Vladimir Kozlov wrote:
>>>>> On 5/13/14 11:49 AM, Filipp Zhinkin wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> please review fix forJDK-8038924.
>>>>>
>>>>> Filipp, please, provide the link to the bug report in you RFR.
>>>> https://bugs.openjdk.java.net/browse/JDK-8038924
>>>>
>>>> Sorry for that, I'l take it in mind for future RFRs.
>>>>>
>>>>>>
>>>>>> CLI tests on BMI-related options previously took all externally 
>>>>>> passed
>>>>>> VM options,
>>>>>> add options that should be tested and launch new VM with such
>>>>>> combination of options.
>>>>>>
>>>>>> Unfortunately, some options like IgnoreUnrecognizedVMOptions, can
>>>>>> affect
>>>>>> processing of tested flags and in such case tests fail.
>>>>>>
>>>>>> I've updated these tests so now they do not use externally passed
>>>>>> options.
>>>>>
>>>>> I don't think it is right solution. Some external flags could be
>>>>> important (DeoptimizeALot for example).
>>>>>
>>>>> You can add -XX:-IgnoreUnrecognizedVMOptions to tests which you 
>>>>> expect
>>>>> to fail (on platforms which does not have the feature). It will
>>>>> nullify this flag passed from CL.
>>>> In general I agree with that point - tests should be able to use as 
>>>> much
>>>> externally passed options as possible.
>>>> However, in this particular case I believe that it would be better to
>>>> ignore such options, because these tests only launch a new VM with 
>>>> tests
>>>> options and '-version' flag,
>>>> so we'll not be able to catch issues that we can't find with other BMI
>>>> tests. And if CLI tests will not use externally passed options it will
>>>> be easier to maintain it.
>>>>
>>>> Note that other BMI-related tests use all externally passed 
>>>> options, so
>>>> we can catch any issues related to JVM behaviour using it.
>>>>
>>>> So I think that it will be better to avoid usage of externally passed
>>>> options in CLI-tests and update compiler/intrinsics/bmi tests to 
>>>> run it
>>>> on all platforms.
>>>>
>>>> Thanks,
>>>> Filipp.
>>>>>
>>>>> Regards,
>>>>> Vladimir
>>>>>
>>>>>> Also, I've fix silly issue with String::format in
>>>>>> BMICommandLineOptionTestBase.java.
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.00/
>>>>>> Testing: manual and automated.
>>>>>>
>>>>>> Thanks,
>>>>>> Filipp.
>>>>
>>


From vladimir.kozlov at oracle.com  Thu May 22 17:53:32 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 22 May 2014 10:53:32 -0700
Subject: RFR (S): JDK-8038924: Test bit-instructions fails with unexpected
	exit value on sparc
In-Reply-To: <537E37E4.2030306@oracle.com>
References: <53726935.90807@oracle.com> <537270D4.9090400@oracle.com>
	<537CA8C0.2030200@oracle.com> <537CEDD5.9070406@oracle.com>
	<537E41FD.1090905@oracle.com> <537CF322.7040507@oracle.com>
	<537E37E4.2030306@oracle.com>
Message-ID: <537E399C.4040608@oracle.com>

Very good.

Thanks,
Vladimir

On 5/22/14 10:46 AM, Filipp Zhinkin wrote:
> Vladimir,
>
> On 05/21/2014 10:40 PM, Vladimir Kozlov wrote:
>> I am okay with changes. I would only suggest to add comment in tests
>> to list what command line will be used when forked VM is executed.
> I agree, it will save a lot of time for everyone who need look at tests'
> sources.
>
> Here is an updated webrev:
> http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.01/
>
> Thanks,
> Filipp.
>>
>> thanks,
>> Vladimir
>>
>> On 5/22/14 11:29 AM, Filipp Zhinkin wrote:
>>> Vladimir,
>>>
>>> so you're OK with this change?
>>>
>>> I've filed an RFE https://bugs.openjdk.java.net/browse/JDK-8043674 for
>>> allowing execution of correctness tests on all platforms.
>>>
>>> Thanks,
>>> Filipp.
>>>
>>> On 05/21/2014 10:17 PM, Vladimir Kozlov wrote:
>>>> Not surprisingly :) I missed that it runs only with -version. It is
>>>> hard to see which options are used. Non of these tests list '-version'
>>>> even in a comment.
>>>>
>>>> I agree that if you fork the same VM (server or client, 32-bit or
>>>> 64-bit) and run it with -version flag you don't need to pass all CL
>>>> options.
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 5/21/14 6:23 AM, Filipp Zhinkin wrote:
>>>>> Vladimir,
>>>>>
>>>>> sorry for a late response.
>>>>>
>>>>> On 05/13/2014 11:21 PM, Vladimir Kozlov wrote:
>>>>>> On 5/13/14 11:49 AM, Filipp Zhinkin wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> please review fix forJDK-8038924.
>>>>>>
>>>>>> Filipp, please, provide the link to the bug report in you RFR.
>>>>> https://bugs.openjdk.java.net/browse/JDK-8038924
>>>>>
>>>>> Sorry for that, I'l take it in mind for future RFRs.
>>>>>>
>>>>>>>
>>>>>>> CLI tests on BMI-related options previously took all externally
>>>>>>> passed
>>>>>>> VM options,
>>>>>>> add options that should be tested and launch new VM with such
>>>>>>> combination of options.
>>>>>>>
>>>>>>> Unfortunately, some options like IgnoreUnrecognizedVMOptions, can
>>>>>>> affect
>>>>>>> processing of tested flags and in such case tests fail.
>>>>>>>
>>>>>>> I've updated these tests so now they do not use externally passed
>>>>>>> options.
>>>>>>
>>>>>> I don't think it is right solution. Some external flags could be
>>>>>> important (DeoptimizeALot for example).
>>>>>>
>>>>>> You can add -XX:-IgnoreUnrecognizedVMOptions to tests which you
>>>>>> expect
>>>>>> to fail (on platforms which does not have the feature). It will
>>>>>> nullify this flag passed from CL.
>>>>> In general I agree with that point - tests should be able to use as
>>>>> much
>>>>> externally passed options as possible.
>>>>> However, in this particular case I believe that it would be better to
>>>>> ignore such options, because these tests only launch a new VM with
>>>>> tests
>>>>> options and '-version' flag,
>>>>> so we'll not be able to catch issues that we can't find with other BMI
>>>>> tests. And if CLI tests will not use externally passed options it will
>>>>> be easier to maintain it.
>>>>>
>>>>> Note that other BMI-related tests use all externally passed
>>>>> options, so
>>>>> we can catch any issues related to JVM behaviour using it.
>>>>>
>>>>> So I think that it will be better to avoid usage of externally passed
>>>>> options in CLI-tests and update compiler/intrinsics/bmi tests to
>>>>> run it
>>>>> on all platforms.
>>>>>
>>>>> Thanks,
>>>>> Filipp.
>>>>>>
>>>>>> Regards,
>>>>>> Vladimir
>>>>>>
>>>>>>> Also, I've fix silly issue with String::format in
>>>>>>> BMICommandLineOptionTestBase.java.
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.00/
>>>>>>> Testing: manual and automated.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Filipp.
>>>>>
>>>
>

From filipp.zhinkin at oracle.com  Thu May 22 17:52:48 2014
From: filipp.zhinkin at oracle.com (Filipp Zhinkin)
Date: Thu, 22 May 2014 21:52:48 +0400
Subject: RFR (S): JDK-8038924: Test bit-instructions fails with unexpected
	exit value on sparc
In-Reply-To: <537E399C.4040608@oracle.com>
References: <53726935.90807@oracle.com> <537270D4.9090400@oracle.com>
	<537CA8C0.2030200@oracle.com> <537CEDD5.9070406@oracle.com>
	<537E41FD.1090905@oracle.com> <537CF322.7040507@oracle.com>
	<537E37E4.2030306@oracle.com> <537E399C.4040608@oracle.com>
Message-ID: <537E3970.3080607@oracle.com>

Vladimir, thank you.

Filipp.

On 05/22/2014 09:53 PM, Vladimir Kozlov wrote:
> Very good.
>
> Thanks,
> Vladimir
>
> On 5/22/14 10:46 AM, Filipp Zhinkin wrote:
>> Vladimir,
>>
>> On 05/21/2014 10:40 PM, Vladimir Kozlov wrote:
>>> I am okay with changes. I would only suggest to add comment in tests
>>> to list what command line will be used when forked VM is executed.
>> I agree, it will save a lot of time for everyone who need look at tests'
>> sources.
>>
>> Here is an updated webrev:
>> http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.01/
>>
>> Thanks,
>> Filipp.
>>>
>>> thanks,
>>> Vladimir
>>>
>>> On 5/22/14 11:29 AM, Filipp Zhinkin wrote:
>>>> Vladimir,
>>>>
>>>> so you're OK with this change?
>>>>
>>>> I've filed an RFE https://bugs.openjdk.java.net/browse/JDK-8043674 for
>>>> allowing execution of correctness tests on all platforms.
>>>>
>>>> Thanks,
>>>> Filipp.
>>>>
>>>> On 05/21/2014 10:17 PM, Vladimir Kozlov wrote:
>>>>> Not surprisingly :) I missed that it runs only with -version. It is
>>>>> hard to see which options are used. Non of these tests list 
>>>>> '-version'
>>>>> even in a comment.
>>>>>
>>>>> I agree that if you fork the same VM (server or client, 32-bit or
>>>>> 64-bit) and run it with -version flag you don't need to pass all CL
>>>>> options.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 5/21/14 6:23 AM, Filipp Zhinkin wrote:
>>>>>> Vladimir,
>>>>>>
>>>>>> sorry for a late response.
>>>>>>
>>>>>> On 05/13/2014 11:21 PM, Vladimir Kozlov wrote:
>>>>>>> On 5/13/14 11:49 AM, Filipp Zhinkin wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> please review fix forJDK-8038924.
>>>>>>>
>>>>>>> Filipp, please, provide the link to the bug report in you RFR.
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8038924
>>>>>>
>>>>>> Sorry for that, I'l take it in mind for future RFRs.
>>>>>>>
>>>>>>>>
>>>>>>>> CLI tests on BMI-related options previously took all externally
>>>>>>>> passed
>>>>>>>> VM options,
>>>>>>>> add options that should be tested and launch new VM with such
>>>>>>>> combination of options.
>>>>>>>>
>>>>>>>> Unfortunately, some options like IgnoreUnrecognizedVMOptions, can
>>>>>>>> affect
>>>>>>>> processing of tested flags and in such case tests fail.
>>>>>>>>
>>>>>>>> I've updated these tests so now they do not use externally passed
>>>>>>>> options.
>>>>>>>
>>>>>>> I don't think it is right solution. Some external flags could be
>>>>>>> important (DeoptimizeALot for example).
>>>>>>>
>>>>>>> You can add -XX:-IgnoreUnrecognizedVMOptions to tests which you
>>>>>>> expect
>>>>>>> to fail (on platforms which does not have the feature). It will
>>>>>>> nullify this flag passed from CL.
>>>>>> In general I agree with that point - tests should be able to use as
>>>>>> much
>>>>>> externally passed options as possible.
>>>>>> However, in this particular case I believe that it would be 
>>>>>> better to
>>>>>> ignore such options, because these tests only launch a new VM with
>>>>>> tests
>>>>>> options and '-version' flag,
>>>>>> so we'll not be able to catch issues that we can't find with 
>>>>>> other BMI
>>>>>> tests. And if CLI tests will not use externally passed options it 
>>>>>> will
>>>>>> be easier to maintain it.
>>>>>>
>>>>>> Note that other BMI-related tests use all externally passed
>>>>>> options, so
>>>>>> we can catch any issues related to JVM behaviour using it.
>>>>>>
>>>>>> So I think that it will be better to avoid usage of externally 
>>>>>> passed
>>>>>> options in CLI-tests and update compiler/intrinsics/bmi tests to
>>>>>> run it
>>>>>> on all platforms.
>>>>>>
>>>>>> Thanks,
>>>>>> Filipp.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Vladimir
>>>>>>>
>>>>>>>> Also, I've fix silly issue with String::format in
>>>>>>>> BMICommandLineOptionTestBase.java.
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~iignatyev/fzhinkin/8038924/webrev.00/
>>>>>>>> Testing: manual and automated.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Filipp.
>>>>>>
>>>>
>>


From kirill.shirokov at oracle.com  Fri May 23 11:47:49 2014
From: kirill.shirokov at oracle.com (Kirill Shirokov)
Date: Fri, 23 May 2014 15:47:49 +0400
Subject: Request for review: JDK-8032970: stack size check methods for
	WhiteBox API
In-Reply-To: <CF3032AB-BE9E-4A48-9EC1-2A2C4F89287A@oracle.com>
References: <52F0F609.3000108@oracle.com> <52F0FC77.709@oracle.com>
	<52F12B6B.1000303@oracle.com> <537399D5.5040807@Oracle.COM>
	<5373BC61.4060700@oracle.com> <537CB806.6080909@oracle.com>
	<1886B65C-AFA0-4B93-832C-31E605BA3F5F@oracle.com>
	<537D1334.1040504@oracle.com>
	<CF3032AB-BE9E-4A48-9EC1-2A2C4F89287A@oracle.com>
Message-ID: <537F3565.8020505@oracle.com>

Hi Christian,

I agree -- that would be more consistent with existing naming. Fixed the 
metod name:
http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.05/

Regards,
Kirill

5/22/2014 2:52 AM, Christian Thalinger wrote:
> I?d prefer just WB_GetThreadStackSize.
>
> On May 21, 2014, at 1:57 PM, Kirill Shirokov 
> <kirill.shirokov at oracle.com <mailto:kirill.shirokov at oracle.com>> wrote:
>
>> WB_GetThreadFullStackSize returns value of JavaThread::stack_size(). 
>> Full here is used to denote 'Full' vs. 'Remaining'.
>>
>> 5/21/2014 9:04 PM, Christian Thalinger ?????:
>>> Quick question:  why is is called *WB_GetThreadFullStackSize*?  What 
>>> defines ?full??
>>>
>>> On May 21, 2014, at 7:28 AM, Kirill Shirokov 
>>> <kirill.shirokov at oracle.com <mailto:kirill.shirokov at oracle.com>> wrote:
>>>
>>>> Hi Vladimir,
>>>>
>>>> Thanks for reviewing. Please see the fixed diff:
>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.04/ 
>>>> <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.04/>
>>>>
>>>> I verified it with -Xint, -Xcomp and -Xmixed on all platforms (32- 
>>>> and 64-bit).
>>>>
>>>> Best regards,
>>>> Kirill
>>>>
>>>> 5/14/2014 10:56 PM, Vladimir Kozlov ?????:
>>>>> Thank you explanation, Kirill
>>>>>
>>>>> WBStackSize.java: please, use more descriptive names for variables:
>>>>>
>>>>> fss < tss * 0.9 || fss > tss
>>>>>
>>>>> You may want to run WBStackSize with -Xint. With compiled code 
>>>>> stack consumption is different. jtreg test could be run with 
>>>>> -Xcomp by harness (during Nightly), please, test such configurations.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 5/14/14 9:29 AM, Kirill Shirokov wrote:
>>>>>> Thanks to all reviewers!
>>>>>>
>>>>>> Could I ask to reivew the fixed patch:
>>>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.03/
>>>>>>
>>>>>> Bug report:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8032970
>>>>>>
>>>>>> The new functions will be used in the existing JSR292 tests -- we 
>>>>>> see a
>>>>>> lot of failures due to StackOverflowError.
>>>>>>
>>>>>> Best regards,
>>>>>> Kirill
>>>>>>
>>>>>> On 02/04/2014 10:03 PM, Vladimir Kozlov wrote:
>>>>>>> Kirill,
>>>>>>>
>>>>>>> You should include link to the bug report and add more explanation
>>>>>>> what this changes for. Will new functions be used in new or existing
>>>>>>> jsr292 tests?
>>>>>>>
>>>>>>> test/testlibrary_tests directory is used for classes used by other
>>>>>>> tests. I think you need to move new test WBStackSize.java into
>>>>>>> test/runtime directory.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir
>>>>>>>
>>>>>>> On 2/4/14 6:43 AM, Kirill Shirokov wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review following webrev, which adds stack size checking 
>>>>>>>> methods
>>>>>>>> to WhiteBox API:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.00/
>>>>>>>> <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.00/>
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Kirill
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140523/bee4f4b6/attachment.html>

From roland.westrelin at oracle.com  Fri May 23 13:16:01 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 23 May 2014 15:16:01 +0200
Subject: 8043413: REGRESSION: Hotspot causes segmentation fault in jdk8ux,
	but not in jdk7ux
Message-ID: <8051C343-144E-43B5-AFD4-54A47B4019AD@oracle.com>

We can have very long call chains of lambda forms in pathological test cases and because we bump _max_inline_level every time we encounter a lambda form, the check for MaxForceInlineLevel is never reached. I suggest we always do the test for MaxForceInlineLevel independently of _max_inline_level and callee_method->force_inline(). I checked that we never reach MaxForceInlineLevel with nashorn.

http://cr.openjdk.java.net/~roland/8043413/webrev.00/

Roland.

From vladimir.x.ivanov at oracle.com  Fri May 23 13:21:25 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 23 May 2014 17:21:25 +0400
Subject: 8043413: REGRESSION: Hotspot causes segmentation fault in jdk8ux, 
	but not in jdk7ux
In-Reply-To: <8051C343-144E-43B5-AFD4-54A47B4019AD@oracle.com>
References: <8051C343-144E-43B5-AFD4-54A47B4019AD@oracle.com>
Message-ID: <537F4B55.5020601@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 5/23/14 5:16 PM, Roland Westrelin wrote:
> We can have very long call chains of lambda forms in pathological test cases and because we bump _max_inline_level every time we encounter a lambda form, the check for MaxForceInlineLevel is never reached. I suggest we always do the test for MaxForceInlineLevel independently of _max_inline_level and callee_method->force_inline(). I checked that we never reach MaxForceInlineLevel with nashorn.
>
> http://cr.openjdk.java.net/~roland/8043413/webrev.00/
>
> Roland.
>

From roland.westrelin at oracle.com  Fri May 23 13:40:59 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 23 May 2014 15:40:59 +0200
Subject: RFR(XS): 8042557:
	compiler/uncommontrap/TestSpecTrapClassUnloading.java fails
	with: GC triggered before VM initialization completed
Message-ID: <6BFD9CFE-A6D0-42C9-901D-29585E7DFB34@oracle.com>

I bumped the heap size to 512M and fixed a bug in the test (thanks Chris).

http://cr.openjdk.java.net/~roland/8042557/webrev.00/

Roland.

From vladimir.x.ivanov at oracle.com  Fri May 23 14:03:35 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 23 May 2014 18:03:35 +0400
Subject: RFR(XS): 8042557:
	compiler/uncommontrap/TestSpecTrapClassUnloading.java
	fails with: GC triggered before VM initialization completed
In-Reply-To: <6BFD9CFE-A6D0-42C9-901D-29585E7DFB34@oracle.com>
References: <6BFD9CFE-A6D0-42C9-901D-29585E7DFB34@oracle.com>
Message-ID: <537F5537.5080900@oracle.com>

Looks good.

As a simplification, you can get rid of MemoryChunk. Considering 
-Xmx512m you can easily provoke OOM by allocating large enough array 
just once.

Best regards,
Vladimir Ivanov

On 5/23/14 5:40 PM, Roland Westrelin wrote:
> I bumped the heap size to 512M and fixed a bug in the test (thanks Chris).
>
> http://cr.openjdk.java.net/~roland/8042557/webrev.00/
>
> Roland.
>

From morris.meyer at oracle.com  Fri May 23 14:30:08 2014
From: morris.meyer at oracle.com (Morris Meyer)
Date: Fri, 23 May 2014 10:30:08 -0400
Subject: RFR(M): 7033917: closed/compiler/6507107/HeapwalkingTest.java
	sometimes works too long
Message-ID: <537F5B70.5040508@oracle.com>

Folks,

During the nightly testing we have a class of bugs that crop up with 
compiler flags that change the performance dynamic of the test, such as 
-Xcomp and -XX:+DeoptimizeALot.

Instead of tweaking the test parameters, I have created an Estimator 
class that takes a work List - and creates an Iterator that is looking 
at the expiration clock for the test.  Instead of the test failing out 
for taking too much time for an arbitrary number of iterations, the 
iterator ends, and Estimator will produce a timeout factor suitable for 
the -Dtest.timeout.factor flag.

I've added an EstimatorTest to testlibrary_tests that tests the 
Estimator with three scenarios, too much time, not enough time and just 
enough time.

This test has also been through JPRT.   The changes HeapwalkingTest will 
be sent out for review to the closed list.

Thanks much,

         --morris meyer


WEBREV - http://cr.openjdk.java.net/~morris/JDK-7033917-hotspot.01
JBS - https://bugs.openjdk.java.net/browse/JDK-7033917



From roland.westrelin at oracle.com  Fri May 23 14:48:31 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Fri, 23 May 2014 16:48:31 +0200
Subject: RFR(M): 8026796: Make replace_in_map() on parent maps generic
In-Reply-To: <537A95D6.9020603@oracle.com>
References: <9F9E2688-4970-4282-A400-F44DB266B149@oracle.com>
	<8E791232-A0F6-4DC2-B40A-2C28D0E1159A@oracle.com>
	<537A95D6.9020603@oracle.com>
Message-ID: <49AC9C55-3889-4C74-92B4-8602EC133557@oracle.com>

Hi Vladimir,

Here is a new webrev that implements your suggestions:

http://cr.openjdk.java.net/~roland/8026796/webrev.01/

Some comments below:

> Why previous code 8024069 does not work?
> 
> 'before', 'after' may not good names. You call new nodes 'improved' in the comment you should use it.
> 
> You meaningful names (not o,n) in record(Node* o, Node* n).
> 
> It would be nice to use getter/setter functions:
> 
> ReplacedNodes r = kit.map()->_replaced_nodes;
> kit.map()->_replaced_nodes = r;
> 
> Do you have cases when ReplacedNodes could be repopulated? So that we reset length GrowableArray::clear() instead of trashing pointer:
> 
> +void ReplacedNodes::reset() {
> +  _replaced_nodes = NULL;
> +}

I don?t think so but it can?t hurt so I?ve made that change.

> I don't see cleanup of ReplacedNodes in Node::destruct() and other places where we clean up expensive nodes, for example.

I added the cleanup to Node::destruct(). Compile::remove_useless_nodes() does the cleanup as well. I don?t understand why it would be needed elsewhere.

> 
> Is the code in Parse::create_entry_map() correct? First, you destroy ReplacedNodes:
> 
>  _caller->map()->delete_replaced_nodes();
> 
> then you used it to initialize new map:
> 
>  SafePointNode* inmap = _caller->map();
>  map()->transfer_replaced_nodes_from(inmap, _new_idx);

    GraphKit kit(_caller);
    kit.null_check_receiver_before_call(method());

between the call to _caller->map()->delete_replaced_nodes() and the map()->transfer_replaced_nodes_from(inmap, _new_idx).

calls replace_in_map() with the caller?s map. map()->transfer_replaced_nodes_from(inmap, _new_idx) is so that we don?t lose track of it.

Roland.

> 
> 
> Thanks,
> Vladimir
> 
> On 5/19/14 4:37 AM, Roland Westrelin wrote:
>> I forgot the webrev:
>> 
>> http://cr.openjdk.java.net/~roland/8026796/webrev.00/
>> 
>> Roland.
>> 
>> On May 19, 2014, at 1:01 PM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
>> 
>>> This change reverts:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8024069
>>> 
>>> and propagates replacements in replace_in_map() to callers in a generic way. Every time replace_in_map() is called, the pair of nodes passed to replace_in_map is pushed on a list that the current map carries. When control flow paths merge, the lists for each of the control flow path?s maps are also merged. When parsing exits a method to return to a caller, the replaced nodes on the exit path are used to update the caller's map. This change also propagates replaced nodes after late inlining.
>>> 
>>> Roland.
>> 


From christian.thalinger at oracle.com  Fri May 23 16:09:51 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 23 May 2014 09:09:51 -0700
Subject: RFR(XS): 8042557:
	compiler/uncommontrap/TestSpecTrapClassUnloading.java fails
	with: GC triggered before VM initialization completed
In-Reply-To: <537F5537.5080900@oracle.com>
References: <6BFD9CFE-A6D0-42C9-901D-29585E7DFB34@oracle.com>
	<537F5537.5080900@oracle.com>
Message-ID: <2C9EC8F4-DA8D-4F84-9194-02B0F590FA0C@oracle.com>


On May 23, 2014, at 7:03 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Looks good.
> 
> As a simplification, you can get rid of MemoryChunk. Considering -Xmx512m you can easily provoke OOM by allocating large enough array just once.

True but we should keep it just in case some is tinkering with the -Xmx value in the future.

> 
> Best regards,
> Vladimir Ivanov
> 
> On 5/23/14 5:40 PM, Roland Westrelin wrote:
>> I bumped the heap size to 512M and fixed a bug in the test (thanks Chris).
>> 
>> http://cr.openjdk.java.net/~roland/8042557/webrev.00/
>> 
>> Roland.
>> 


From christian.thalinger at oracle.com  Fri May 23 16:10:13 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 23 May 2014 09:10:13 -0700
Subject: RFR(XS): 8042557:
	compiler/uncommontrap/TestSpecTrapClassUnloading.java fails
	with: GC triggered before VM initialization completed
In-Reply-To: <6BFD9CFE-A6D0-42C9-901D-29585E7DFB34@oracle.com>
References: <6BFD9CFE-A6D0-42C9-901D-29585E7DFB34@oracle.com>
Message-ID: <8D460915-4628-4B18-B3AA-2E7AAC47A770@oracle.com>

Looks good.

On May 23, 2014, at 6:40 AM, Roland Westrelin <roland.westrelin at oracle.com> wrote:

> I bumped the heap size to 512M and fixed a bug in the test (thanks Chris).
> 
> http://cr.openjdk.java.net/~roland/8042557/webrev.00/
> 
> Roland.


From vladimir.kozlov at oracle.com  Fri May 23 16:12:13 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 23 May 2014 09:12:13 -0700
Subject: RFR(XS): 8042557:
	compiler/uncommontrap/TestSpecTrapClassUnloading.java
	fails with: GC triggered before VM initialization completed
In-Reply-To: <6BFD9CFE-A6D0-42C9-901D-29585E7DFB34@oracle.com>
References: <6BFD9CFE-A6D0-42C9-901D-29585E7DFB34@oracle.com>
Message-ID: <537F735D.7020203@oracle.com>

Good.

Vladimir

On 5/23/14 6:40 AM, Roland Westrelin wrote:
> I bumped the heap size to 512M and fixed a bug in the test (thanks Chris).
>
> http://cr.openjdk.java.net/~roland/8042557/webrev.00/
>
> Roland.
>

From vladimir.kozlov at oracle.com  Fri May 23 16:43:01 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 23 May 2014 09:43:01 -0700
Subject: 8043413: REGRESSION: Hotspot causes segmentation fault in jdk8ux, 
	but not in jdk7ux
In-Reply-To: <8051C343-144E-43B5-AFD4-54A47B4019AD@oracle.com>
References: <8051C343-144E-43B5-AFD4-54A47B4019AD@oracle.com>
Message-ID: <537F7A95.10707@oracle.com>

Good.

Vladimir

On 5/23/14 6:16 AM, Roland Westrelin wrote:
> We can have very long call chains of lambda forms in pathological test cases and because we bump _max_inline_level every time we encounter a lambda form, the check for MaxForceInlineLevel is never reached. I suggest we always do the test for MaxForceInlineLevel independently of _max_inline_level and callee_method->force_inline(). I checked that we never reach MaxForceInlineLevel with nashorn.
>
> http://cr.openjdk.java.net/~roland/8043413/webrev.00/
>
> Roland.
>

From christian.thalinger at oracle.com  Fri May 23 16:52:20 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 23 May 2014 09:52:20 -0700
Subject: Request for review: JDK-8032970: stack size check methods for
	WhiteBox API
In-Reply-To: <537F3565.8020505@oracle.com>
References: <52F0F609.3000108@oracle.com> <52F0FC77.709@oracle.com>
	<52F12B6B.1000303@oracle.com> <537399D5.5040807@Oracle.COM>
	<5373BC61.4060700@oracle.com> <537CB806.6080909@oracle.com>
	<1886B65C-AFA0-4B93-832C-31E605BA3F5F@oracle.com>
	<537D1334.1040504@oracle.com>
	<CF3032AB-BE9E-4A48-9EC1-2A2C4F89287A@oracle.com>
	<537F3565.8020505@oracle.com>
Message-ID: <C3F71670-F5E6-4A6A-8F42-E19D63052CFD@oracle.com>

Thanks.  Looks good.

On May 23, 2014, at 4:47 AM, Kirill Shirokov <kirill.shirokov at oracle.com> wrote:

> Hi Christian,
> 
> I agree -- that would be more consistent with existing naming. Fixed the metod name:
> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.05/
> 
> Regards,
> Kirill
> 
> 5/22/2014 2:52 AM, Christian Thalinger wrote:
>> I?d prefer just WB_GetThreadStackSize.
>> 
>> On May 21, 2014, at 1:57 PM, Kirill Shirokov <kirill.shirokov at oracle.com <mailto:kirill.shirokov at oracle.com>> wrote:
>> 
>>> WB_GetThreadFullStackSize returns value of JavaThread::stack_size(). Full here is used to denote 'Full' vs. 'Remaining'.
>>> 
>>> 5/21/2014 9:04 PM, Christian Thalinger ?????:
>>>> Quick question:  why is is called *WB_GetThreadFullStackSize*?  What defines ?full??
>>>> 
>>>> On May 21, 2014, at 7:28 AM, Kirill Shirokov <kirill.shirokov at oracle.com <mailto:kirill.shirokov at oracle.com>> wrote:
>>>> 
>>>>> Hi Vladimir,
>>>>> 
>>>>> Thanks for reviewing. Please see the fixed diff:
>>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.04/ <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.04/>
>>>>> 
>>>>> I verified it with -Xint, -Xcomp and -Xmixed on all platforms (32- and 64-bit).
>>>>> 
>>>>> Best regards,
>>>>> Kirill
>>>>> 
>>>>> 5/14/2014 10:56 PM, Vladimir Kozlov ?????:
>>>>>> Thank you explanation, Kirill
>>>>>> 
>>>>>> WBStackSize.java: please, use more descriptive names for variables:
>>>>>> 
>>>>>> fss < tss * 0.9 || fss > tss
>>>>>> 
>>>>>> You may want to run WBStackSize with -Xint. With compiled code stack consumption is different. jtreg test could be run with -Xcomp by harness (during Nightly), please, test such configurations.
>>>>>> 
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>> 
>>>>>> On 5/14/14 9:29 AM, Kirill Shirokov wrote:
>>>>>>> Thanks to all reviewers!
>>>>>>> 
>>>>>>> Could I ask to reivew the fixed patch:
>>>>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.03/
>>>>>>> 
>>>>>>> Bug report:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8032970
>>>>>>> 
>>>>>>> The new functions will be used in the existing JSR292 tests -- we see a
>>>>>>> lot of failures due to StackOverflowError.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Kirill
>>>>>>> 
>>>>>>> On 02/04/2014 10:03 PM, Vladimir Kozlov wrote:
>>>>>>>> Kirill,
>>>>>>>> 
>>>>>>>> You should include link to the bug report and add more explanation
>>>>>>>> what this changes for. Will new functions be used in new or existing
>>>>>>>> jsr292 tests?
>>>>>>>> 
>>>>>>>> test/testlibrary_tests directory is used for classes used by other
>>>>>>>> tests. I think you need to move new test WBStackSize.java into
>>>>>>>> test/runtime directory.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Vladimir
>>>>>>>> 
>>>>>>>> On 2/4/14 6:43 AM, Kirill Shirokov wrote:
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Please review following webrev, which adds stack size checking methods
>>>>>>>>> to WhiteBox API:
>>>>>>>>> 
>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/kshirokov/8032970/webrev.00/
>>>>>>>>> <http://cr.openjdk.java.net/%7Eiignatyev/kshirokov/8032970/webrev.00/>
>>>>>>>>> 
>>>>>>>>> Thank you,
>>>>>>>>> Kirill
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From igor.veresov at oracle.com  Fri May 23 19:53:07 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Fri, 23 May 2014 09:53:07 -1000
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't
	enter safepoint
In-Reply-To: <99AC6EE8-932C-40FC-8834-4667DE25BF9B@oracle.com>
References: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
	<6B76419A-328B-4D00-A8BF-FA9E5AEBD220@oracle.com>
	<1679027.HDHsSq8pUN@mgerdin03> <7613371.caJJoI3tB6@mgerdin03>
	<99AC6EE8-932C-40FC-8834-4667DE25BF9B@oracle.com>
Message-ID: <E7711A25-DAC1-47D6-985E-1B726B53D7CE@oracle.com>

So, I went back to this bug and here is the actual root cause of the problem... I was running stress tests with  -XX:MinPassesBeforeFlush=0 and a very small code cache, which created a race between the method installation (in ciEnv::register_method()) and the flusher. Methods were flushed right after we released the CodeCache_lock in nmethod::new_nmethod(), and that?s the reason the verification thought that the installation has finished since the method wasn?t in use. It?s also btw pretty dangerous to do an nmethod state transition from in_use to not_entrant before the code pointer is installed - we don?t clean it up later when we transition from not_entrant to zombie (and we can?t).

Anyways, the solution is pretty straightforward, we must not flush an nmethod before it?s fully installed (that is until the code pointer is published).
Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.02/

Thanks,
igor




From vladimir.kozlov at oracle.com  Fri May 23 22:22:11 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 23 May 2014 15:22:11 -0700
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't
	enter safepoint
In-Reply-To: <E7711A25-DAC1-47D6-985E-1B726B53D7CE@oracle.com>
References: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>	<6B76419A-328B-4D00-A8BF-FA9E5AEBD220@oracle.com>	<1679027.HDHsSq8pUN@mgerdin03>
	<7613371.caJJoI3tB6@mgerdin03>	<99AC6EE8-932C-40FC-8834-4667DE25BF9B@oracle.com>
	<E7711A25-DAC1-47D6-985E-1B726B53D7CE@oracle.com>
Message-ID: <537FCA13.3080407@oracle.com>

I remember someone (Vladimir Ivanov?) wanted to add additional state to 
nmethod to track installation phase. Because it could be other cases 
when nm != nm->method()->code(). What about OSR nmethods?

Thanks,
Vladimir

On 5/23/14 12:53 PM, Igor Veresov wrote:
> So, I went back to this bug and here is the actual root cause of the problem... I was running stress tests with  -XX:MinPassesBeforeFlush=0 and a very small code cache, which created a race between the method installation (in ciEnv::register_method()) and the flusher. Methods were flushed right after we released the CodeCache_lock in nmethod::new_nmethod(), and that?s the reason the verification thought that the installation has finished since the method wasn?t in use. It?s also btw pretty dangerous to do an nmethod state transition from in_use to not_entrant before the code pointer is installed - we don?t clean it up later when we transition from not_entrant to zombie (and we can?t).
>
> Anyways, the solution is pretty straightforward, we must not flush an nmethod before it?s fully installed (that is until the code pointer is published).
> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.02/
>
> Thanks,
> igor
>
>
>

From igor.veresov at oracle.com  Fri May 23 22:35:28 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Fri, 23 May 2014 12:35:28 -1000
Subject: RFR(XS): 8043070: nmethod::verify_interrupt_point() shouldn't
	enter safepoint
In-Reply-To: <537FCA13.3080407@oracle.com>
References: <6B32A45F-8931-4291-9C3C-156AC7A6316E@oracle.com>
	<6B76419A-328B-4D00-A8BF-FA9E5AEBD220@oracle.com>
	<1679027.HDHsSq8pUN@mgerdin03> <7613371.caJJoI3tB6@mgerdin03>
	<99AC6EE8-932C-40FC-8834-4667DE25BF9B@oracle.com>
	<E7711A25-DAC1-47D6-985E-1B726B53D7CE@oracle.com>
	<537FCA13.3080407@oracle.com>
Message-ID: <A951A0A4-C44E-42E6-8641-F6322C732A85@oracle.com>

We don't flush OSRs, but you're right - a separate state should be a cleaner and more future proof (multiple code versions) solution. I'll make the change and add the state.

igor

> On May 23, 2014, at 12:22 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> I remember someone (Vladimir Ivanov?) wanted to add additional state to nmethod to track installation phase. Because it could be other cases when nm != nm->method()->code(). What about OSR nmethods?
> 
> Thanks,
> Vladimir
> 
>> On 5/23/14 12:53 PM, Igor Veresov wrote:
>> So, I went back to this bug and here is the actual root cause of the problem... I was running stress tests with  -XX:MinPassesBeforeFlush=0 and a very small code cache, which created a race between the method installation (in ciEnv::register_method()) and the flusher. Methods were flushed right after we released the CodeCache_lock in nmethod::new_nmethod(), and that?s the reason the verification thought that the installation has finished since the method wasn?t in use. It?s also btw pretty dangerous to do an nmethod state transition from in_use to not_entrant before the code pointer is installed - we don?t clean it up later when we transition from not_entrant to zombie (and we can?t).
>> 
>> Anyways, the solution is pretty straightforward, we must not flush an nmethod before it?s fully installed (that is until the code pointer is published).
>> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.02/
>> 
>> Thanks,
>> igor
>> 
>> 
>> 

From roland.westrelin at oracle.com  Mon May 26 08:55:06 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 26 May 2014 10:55:06 +0200
Subject: RFR(XS): 8042557:
	compiler/uncommontrap/TestSpecTrapClassUnloading.java fails
	with: GC triggered before VM initialization completed
In-Reply-To: <537F735D.7020203@oracle.com>
References: <6BFD9CFE-A6D0-42C9-901D-29585E7DFB34@oracle.com>
	<537F735D.7020203@oracle.com>
Message-ID: <6C8D0F90-7E56-4D9C-9ED2-4D56EE465F43@oracle.com>

Thanks for the review Vladimir, Vladimir and Chris.

Roland.

From roland.westrelin at oracle.com  Mon May 26 12:12:27 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 26 May 2014 14:12:27 +0200
Subject: 8043413: REGRESSION: Hotspot causes segmentation fault in jdk8ux,
	but not in jdk7ux
In-Reply-To: <537F7A95.10707@oracle.com>
References: <8051C343-144E-43B5-AFD4-54A47B4019AD@oracle.com>
	<537F7A95.10707@oracle.com>
Message-ID: <149BFAB6-D716-4FF0-AA25-D6A55EED5EE2@oracle.com>

Thanks for the review Vladimir & Vladimir.

Roland.


On May 23, 2014, at 6:43 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Good.
> 
> Vladimir
> 
> On 5/23/14 6:16 AM, Roland Westrelin wrote:
>> We can have very long call chains of lambda forms in pathological test cases and because we bump _max_inline_level every time we encounter a lambda form, the check for MaxForceInlineLevel is never reached. I suggest we always do the test for MaxForceInlineLevel independently of _max_inline_level and callee_method->force_inline(). I checked that we never reach MaxForceInlineLevel with nashorn.
>> 
>> http://cr.openjdk.java.net/~roland/8043413/webrev.00/
>> 
>> Roland.
>> 


From roland.westrelin at oracle.com  Mon May 26 12:33:46 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 26 May 2014 14:33:46 +0200
Subject: RFR(S): 8043638: Multiple compilation attempts break
	LogCompulation, lead to confusing PrintInlining output
In-Reply-To: <537CEBA8.1030505@oracle.com>
References: <88C17474-AA34-4A67-906E-9016768EC3A9@oracle.com>
	<537CEBA8.1030505@oracle.com>
Message-ID: <9627389E-968C-4816-B40D-8DE3A2249196@oracle.com>

Thanks, Vladimir?

Any one else for this simple review?

Roland.

On May 21, 2014, at 8:08 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Looks good.
> 
> Vladimir
> 
> On 5/21/14 7:22 AM, Roland Westrelin wrote:
>> When C2 attempts the compilation of a method multiple times:
>> 
>> 1) the PrintInlining output shows inlining decisions for all attempts together (if compilation failure happens late in the compilation process)
>> 2) the log of the multiple attempts confuses the LogCompilation tool.
>> 
>> http://cr.openjdk.java.net/~roland/8043638/webrev.00/
>> 
>> Roland.
>> 


From vladimir.x.ivanov at oracle.com  Mon May 26 12:39:01 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 26 May 2014 16:39:01 +0400
Subject: RFR(S): 8043638: Multiple compilation attempts break
	LogCompulation, lead to confusing PrintInlining output
In-Reply-To: <88C17474-AA34-4A67-906E-9016768EC3A9@oracle.com>
References: <88C17474-AA34-4A67-906E-9016768EC3A9@oracle.com>
Message-ID: <538335E5.1080206@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 5/21/14 6:22 PM, Roland Westrelin wrote:
> When C2 attempts the compilation of a method multiple times:
>
> 1) the PrintInlining output shows inlining decisions for all attempts together (if compilation failure happens late in the compilation process)
> 2) the log of the multiple attempts confuses the LogCompilation tool.
>
> http://cr.openjdk.java.net/~roland/8043638/webrev.00/
>
> Roland.
>

From roland.westrelin at oracle.com  Mon May 26 12:39:44 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Mon, 26 May 2014 14:39:44 +0200
Subject: RFR(S): 8043638: Multiple compilation attempts break
	LogCompulation, lead to confusing PrintInlining output
In-Reply-To: <538335E5.1080206@oracle.com>
References: <88C17474-AA34-4A67-906E-9016768EC3A9@oracle.com>
	<538335E5.1080206@oracle.com>
Message-ID: <86F83857-7397-49A3-9EE4-AA7946977F84@oracle.com>

Thank you, Vladimir!

Roland.

On May 26, 2014, at 2:39 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Looks good.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 5/21/14 6:22 PM, Roland Westrelin wrote:
>> When C2 attempts the compilation of a method multiple times:
>> 
>> 1) the PrintInlining output shows inlining decisions for all attempts together (if compilation failure happens late in the compilation process)
>> 2) the log of the multiple attempts confuses the LogCompilation tool.
>> 
>> http://cr.openjdk.java.net/~roland/8043638/webrev.00/
>> 
>> Roland.
>> 


From igor.ignatyev at oracle.com  Mon May 26 13:34:49 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 26 May 2014 17:34:49 +0400
Subject: RFR(XXS) : 8043899: compiler/5091921/Test7005594.java fails if
	specified -Xmx is less than 1600m
Message-ID: <538342F9.2090202@oracle.com>

http://cr.openjdk.java.net/~iignatyev/8043899/webrev.00/
3 lines changed: 0 ins; 1 del; 2 mod;

Hi all,

Please review patch:

Problem:
- the test specifies '-Xms' equal to 1600m. so it will fail, if the 
harness passes '-Xmx' which is less than 1600m.
- 8015007 changed the error message in Universe::reserve_heap()
>     946   if (!total_rs.is_reserved()) {
>     947     vm_exit_during_initialization(err_msg("Could not reserve enough space for " SIZE_FORMAT "KB object heap", total_reserved/K));
>     948     return total_rs;
>     949   }
the test treats this message as a failure.

Fix:
- set Xmx to 1600m
- change the pattern of allowable error message

jbs: https://bugs.openjdk.java.net/browse/JDK-8043899
testing: failing tests in jprt
-- 
Igor

From vladimir.x.ivanov at oracle.com  Mon May 26 19:25:14 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 26 May 2014 23:25:14 +0400
Subject: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling
	with DirectMethodHandle
Message-ID: <5383951A.1070104@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8034935
http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00

Citing John's explanation of motivation for this change (from the bug):
"There is a coupling from bytecodes that call MethodHandle.linkToStatic 
(and similar "linker methods") and the PopFrame feature. The linker 
methods accept an extra "appendix argument" of type MemberName which is 
popped from the list before vectoring to the desired method (it supplies 
the name of that method).

In order to re-execute the call, the MemberName must be recovered 
somehow. Currently, the JVM assumes that the interpreter frame's local 
#0 will contain a DirectMethodHandle which holds the desired MemberName. 
The JVM should also accept the MemberName itself, and eventually stop 
looking for the DirectMethodHandle.

This will simplify the handshake between JVM and JSR 292 implementation 
bytecodes. The DMH is difficult to recover at the point of call to 
linkToStatic, although the MemberName is guaranteed live at that point.

Also, making this change (perhaps in two steps) will allow the JVM to 
stop coupling to SystemDictionary::DirectMethodHandle_klass. Such 
couplings should be minimized."

Testing: JPRT, jtreg (java/lang/invoke), vm.mlvm.testlist

Thanks!

Best regards,
Vladimir Ivanov

From vladimir.x.ivanov at oracle.com  Tue May 27 14:21:30 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 27 May 2014 18:21:30 +0400
Subject: RFR(XXS) : 8043899: compiler/5091921/Test7005594.java fails if
	specified -Xmx is less than 1600m
In-Reply-To: <538342F9.2090202@oracle.com>
References: <538342F9.2090202@oracle.com>
Message-ID: <53849F6A.60302@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 5/26/14 5:34 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8043899/webrev.00/
> 3 lines changed: 0 ins; 1 del; 2 mod;
>
> Hi all,
>
> Please review patch:
>
> Problem:
> - the test specifies '-Xms' equal to 1600m. so it will fail, if the
> harness passes '-Xmx' which is less than 1600m.
> - 8015007 changed the error message in Universe::reserve_heap()
>>     946   if (!total_rs.is_reserved()) {
>>     947     vm_exit_during_initialization(err_msg("Could not reserve
>> enough space for " SIZE_FORMAT "KB object heap", total_reserved/K));
>>     948     return total_rs;
>>     949   }
> the test treats this message as a failure.
>
> Fix:
> - set Xmx to 1600m
> - change the pattern of allowable error message
>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8043899
> testing: failing tests in jprt

From christian.thalinger at oracle.com  Tue May 27 17:05:45 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 27 May 2014 10:05:45 -0700
Subject: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling
	with DirectMethodHandle
In-Reply-To: <5383951A.1070104@oracle.com>
References: <5383951A.1070104@oracle.com>
Message-ID: <73F67166-6300-4502-9747-0BFCC510CF32@oracle.com>

Looks good.  Would be good to put a FIXME on the comment as well so we don?t forget to remove it.

On May 26, 2014, at 12:25 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8034935
> http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00
> 
> Citing John's explanation of motivation for this change (from the bug):
> "There is a coupling from bytecodes that call MethodHandle.linkToStatic (and similar "linker methods") and the PopFrame feature. The linker methods accept an extra "appendix argument" of type MemberName which is popped from the list before vectoring to the desired method (it supplies the name of that method).
> 
> In order to re-execute the call, the MemberName must be recovered somehow. Currently, the JVM assumes that the interpreter frame's local #0 will contain a DirectMethodHandle which holds the desired MemberName. The JVM should also accept the MemberName itself, and eventually stop looking for the DirectMethodHandle.
> 
> This will simplify the handshake between JVM and JSR 292 implementation bytecodes. The DMH is difficult to recover at the point of call to linkToStatic, although the MemberName is guaranteed live at that point.
> 
> Also, making this change (perhaps in two steps) will allow the JVM to stop coupling to SystemDictionary::DirectMethodHandle_klass. Such couplings should be minimized."
> 
> Testing: JPRT, jtreg (java/lang/invoke), vm.mlvm.testlist
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov


From christian.thalinger at oracle.com  Tue May 27 17:07:27 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 27 May 2014 10:07:27 -0700
Subject: RFR(XXS) : 8043899: compiler/5091921/Test7005594.java fails if
	specified -Xmx is less than 1600m
In-Reply-To: <538342F9.2090202@oracle.com>
References: <538342F9.2090202@oracle.com>
Message-ID: <202DABF3-D697-4BB2-9779-C7697FC36F13@oracle.com>

Looks good.

On May 26, 2014, at 6:34 AM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:

> http://cr.openjdk.java.net/~iignatyev/8043899/webrev.00/
> 3 lines changed: 0 ins; 1 del; 2 mod;
> 
> Hi all,
> 
> Please review patch:
> 
> Problem:
> - the test specifies '-Xms' equal to 1600m. so it will fail, if the harness passes '-Xmx' which is less than 1600m.
> - 8015007 changed the error message in Universe::reserve_heap()
>>    946   if (!total_rs.is_reserved()) {
>>    947     vm_exit_during_initialization(err_msg("Could not reserve enough space for " SIZE_FORMAT "KB object heap", total_reserved/K));
>>    948     return total_rs;
>>    949   }
> the test treats this message as a failure.
> 
> Fix:
> - set Xmx to 1600m
> - change the pattern of allowable error message
> 
> jbs: https://bugs.openjdk.java.net/browse/JDK-8043899
> testing: failing tests in jprt
> -- 
> Igor


From vladimir.kozlov at oracle.com  Tue May 27 17:08:26 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 27 May 2014 10:08:26 -0700
Subject: RFR(XXS) : 8043899: compiler/5091921/Test7005594.java fails if
	specified -Xmx is less than 1600m
In-Reply-To: <538342F9.2090202@oracle.com>
References: <538342F9.2090202@oracle.com>
Message-ID: <5384C68A.4030602@oracle.com>

Good.

Vladimir

On 5/26/14 6:34 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8043899/webrev.00/
> 3 lines changed: 0 ins; 1 del; 2 mod;
>
> Hi all,
>
> Please review patch:
>
> Problem:
> - the test specifies '-Xms' equal to 1600m. so it will fail, if the
> harness passes '-Xmx' which is less than 1600m.
> - 8015007 changed the error message in Universe::reserve_heap()
>>     946   if (!total_rs.is_reserved()) {
>>     947     vm_exit_during_initialization(err_msg("Could not reserve
>> enough space for " SIZE_FORMAT "KB object heap", total_reserved/K));
>>     948     return total_rs;
>>     949   }
> the test treats this message as a failure.
>
> Fix:
> - set Xmx to 1600m
> - change the pattern of allowable error message
>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8043899
> testing: failing tests in jprt

From vladimir.x.ivanov at oracle.com  Tue May 27 17:12:57 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 27 May 2014 21:12:57 +0400
Subject: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling
	with DirectMethodHandle
In-Reply-To: <73F67166-6300-4502-9747-0BFCC510CF32@oracle.com>
References: <5383951A.1070104@oracle.com>
	<73F67166-6300-4502-9747-0BFCC510CF32@oracle.com>
Message-ID: <5384C799.7090408@oracle.com>

Thanks, Chris.

Will replicate FIXME comment at the end of method comment preamble as well.

Best regards,
Vladimir Ivanov

On 5/27/14 9:05 PM, Christian Thalinger wrote:
> Looks good.  Would be good to put a FIXME on the comment as well so we don?t forget to remove it.
>
> On May 26, 2014, at 12:25 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> https://bugs.openjdk.java.net/browse/JDK-8034935
>> http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00
>>
>> Citing John's explanation of motivation for this change (from the bug):
>> "There is a coupling from bytecodes that call MethodHandle.linkToStatic (and similar "linker methods") and the PopFrame feature. The linker methods accept an extra "appendix argument" of type MemberName which is popped from the list before vectoring to the desired method (it supplies the name of that method).
>>
>> In order to re-execute the call, the MemberName must be recovered somehow. Currently, the JVM assumes that the interpreter frame's local #0 will contain a DirectMethodHandle which holds the desired MemberName. The JVM should also accept the MemberName itself, and eventually stop looking for the DirectMethodHandle.
>>
>> This will simplify the handshake between JVM and JSR 292 implementation bytecodes. The DMH is difficult to recover at the point of call to linkToStatic, although the MemberName is guaranteed live at that point.
>>
>> Also, making this change (perhaps in two steps) will allow the JVM to stop coupling to SystemDictionary::DirectMethodHandle_klass. Such couplings should be minimized."
>>
>> Testing: JPRT, jtreg (java/lang/invoke), vm.mlvm.testlist
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>

From john.r.rose at oracle.com  Wed May 28 00:11:48 2014
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 27 May 2014 17:11:48 -0700
Subject: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling
	with DirectMethodHandle
In-Reply-To: <5383951A.1070104@oracle.com>
References: <5383951A.1070104@oracle.com>
Message-ID: <1582EDFE-6B58-4888-B94D-3C7552241697@oracle.com>

Reviewed; thank you.  ? John

On May 26, 2014, at 12:25 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140527/2efa056a/attachment.html>

From serguei.spitsyn at oracle.com  Wed May 28 05:37:18 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 27 May 2014 22:37:18 -0700
Subject: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling
	with DirectMethodHandle
In-Reply-To: <5383951A.1070104@oracle.com>
References: <5383951A.1070104@oracle.com>
Message-ID: <5385760E.3040109@oracle.com>

Vladimir,

It looks good.

Thanks,
Serguei

On 5/26/14 12:25 PM, Vladimir Ivanov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8034935
> http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00
>
> Citing John's explanation of motivation for this change (from the bug):
> "There is a coupling from bytecodes that call 
> MethodHandle.linkToStatic (and similar "linker methods") and the 
> PopFrame feature. The linker methods accept an extra "appendix 
> argument" of type MemberName which is popped from the list before 
> vectoring to the desired method (it supplies the name of that method).
>
> In order to re-execute the call, the MemberName must be recovered 
> somehow. Currently, the JVM assumes that the interpreter frame's local 
> #0 will contain a DirectMethodHandle which holds the desired 
> MemberName. The JVM should also accept the MemberName itself, and 
> eventually stop looking for the DirectMethodHandle.
>
> This will simplify the handshake between JVM and JSR 292 
> implementation bytecodes. The DMH is difficult to recover at the point 
> of call to linkToStatic, although the MemberName is guaranteed live at 
> that point.
>
> Also, making this change (perhaps in two steps) will allow the JVM to 
> stop coupling to SystemDictionary::DirectMethodHandle_klass. Such 
> couplings should be minimized."
>
> Testing: JPRT, jtreg (java/lang/invoke), vm.mlvm.testlist
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov


From igor.veresov at oracle.com  Wed May 28 06:38:25 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Tue, 27 May 2014 20:38:25 -1000
Subject: RFR(XS): 8044090: C1: Old value instead of new one is passed to
	post-barrier in UnsafeGetAndSetObject
Message-ID: <F98F5E3F-8CE2-4F22-BA61-D6714C417B1E@oracle.com>

I didn?t notice this before but in UnsafeGetAndSetObject on C1 SPARC we?re passing an old value (which we are getting as a result of the xchg) to the post-barrier, while it really expect the new value (what was stored into memory).

Webrev: http://cr.openjdk.java.net/~iveresov/8044090/webrev.00/

Thanks!
igor

From tobias.hartmann at oracle.com  Wed May 28 07:42:26 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 28 May 2014 09:42:26 +0200
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <53753144.5060707@oracle.com>
References: <53750D18.6040201@oracle.com> <53753144.5060707@oracle.com>
Message-ID: <53859362.9010700@oracle.com>

Hi Vladimir,

as you suggested, I tested the fix both on x86 and sparc by running 
Octane with -Xcomp and -XX:-TieredCompilation and measured the 
compilation speed. There is no regression. I attached the results [1] to 
the bug.

I also executed SPECjbb2005, SPECjbb2013 and SPECjvm2008-Compiler on 
Perf-Aurora to make sure that there is no performance regression. I 
posted the link in the bug description.

Thanks,
Tobias


[1]
-- x86_64, Solaris --

Baseline
   Score: 150.8 (+- 2.1)
   Compilation speed: 31548.7 bytes/s (+- 247.67)
Fix
   Score: 151.1 (+- 1.86)
   Compilaion speed: 31878.5 bytes/s (+- 195.88)


-- Sparc, Solaris --

Baseline
   Score: 17.46 (+- 0.11)
   Compilation speed: 4342.5 (+- 55.32)
Fix
   Score: 17.4 (+- 0.13)
   Compilation speed: 4349.5 (+- 69.66)


The numbers in brackets show the 95% confidence interval.


On 15.05.2014 23:27, Vladimir Kozlov wrote:
> Tobias,
>
> Changes are fine but I am concern about compilation speed.
> Please, test compilation performance (-XX:+TimeCompiler) on x86 and 
> sparc. You need to build optimized VM for that to exclude assert but 
> keep statistic code. I would suggest to run one of nashorn octane 
> benchmarks with -Xcomp -XX:-TieredCompilation to get compilation with 
> big graphs.
>
> Thanks,
> Vladimir
>
> On 5/15/14 11:53 AM, Tobias Hartmann wrote:
>> Hi,
>>
>> please review the following patch that removes the IDX_INIT macro used
>> by Node::Node(...) to retrieve the Compile object and replaces it by a
>> call to Compile::current(). The Node constructor, new operator and all
>> calls to it are adapted accordingly.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
>> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
>>
>> Tested with JPRT.
>>
>> Thanks,
>> Tobias


From vladimir.kozlov at oracle.com  Wed May 28 07:49:43 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 28 May 2014 00:49:43 -0700
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <53859362.9010700@oracle.com>
References: <53750D18.6040201@oracle.com> <53753144.5060707@oracle.com>
	<53859362.9010700@oracle.com>
Message-ID: <53859517.7060102@oracle.com>

Thank you, Tobias, for this testing. I remove my concern. Changes are good.

Thanks,
Vladimir

On 5/28/14 12:42 AM, Tobias Hartmann wrote:
> Hi Vladimir,
>
> as you suggested, I tested the fix both on x86 and sparc by running Octane with -Xcomp and -XX:-TieredCompilation and
> measured the compilation speed. There is no regression. I attached the results [1] to the bug.
>
> I also executed SPECjbb2005, SPECjbb2013 and SPECjvm2008-Compiler on Perf-Aurora to make sure that there is no
> performance regression. I posted the link in the bug description.
>
> Thanks,
> Tobias
>
>
> [1]
> -- x86_64, Solaris --
>
> Baseline
>    Score: 150.8 (+- 2.1)
>    Compilation speed: 31548.7 bytes/s (+- 247.67)
> Fix
>    Score: 151.1 (+- 1.86)
>    Compilaion speed: 31878.5 bytes/s (+- 195.88)
>
>
> -- Sparc, Solaris --
>
> Baseline
>    Score: 17.46 (+- 0.11)
>    Compilation speed: 4342.5 (+- 55.32)
> Fix
>    Score: 17.4 (+- 0.13)
>    Compilation speed: 4349.5 (+- 69.66)
>
>
> The numbers in brackets show the 95% confidence interval.
>
>
> On 15.05.2014 23:27, Vladimir Kozlov wrote:
>> Tobias,
>>
>> Changes are fine but I am concern about compilation speed.
>> Please, test compilation performance (-XX:+TimeCompiler) on x86 and sparc. You need to build optimized VM for that to
>> exclude assert but keep statistic code. I would suggest to run one of nashorn octane benchmarks with -Xcomp
>> -XX:-TieredCompilation to get compilation with big graphs.
>>
>> Thanks,
>> Vladimir
>>
>> On 5/15/14 11:53 AM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> please review the following patch that removes the IDX_INIT macro used
>>> by Node::Node(...) to retrieve the Compile object and replaces it by a
>>> call to Compile::current(). The Node constructor, new operator and all
>>> calls to it are adapted accordingly.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
>>> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
>>>
>>> Tested with JPRT.
>>>
>>> Thanks,
>>> Tobias
>

From tobias.hartmann at oracle.com  Wed May 28 08:12:17 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 28 May 2014 10:12:17 +0200
Subject: [9] RFR(L): 8034812: remove IDX_INIT macro hack in Node class
In-Reply-To: <53859517.7060102@oracle.com>
References: <53750D18.6040201@oracle.com> <53753144.5060707@oracle.com>
	<53859362.9010700@oracle.com> <53859517.7060102@oracle.com>
Message-ID: <53859A61.5020108@oracle.com>

Thank you, Vladimir.

Best,
Tobias

On 28.05.2014 09:49, Vladimir Kozlov wrote:
> Thank you, Tobias, for this testing. I remove my concern. Changes are 
> good.
>
> Thanks,
> Vladimir
>
> On 5/28/14 12:42 AM, Tobias Hartmann wrote:
>> Hi Vladimir,
>>
>> as you suggested, I tested the fix both on x86 and sparc by running 
>> Octane with -Xcomp and -XX:-TieredCompilation and
>> measured the compilation speed. There is no regression. I attached 
>> the results [1] to the bug.
>>
>> I also executed SPECjbb2005, SPECjbb2013 and SPECjvm2008-Compiler on 
>> Perf-Aurora to make sure that there is no
>> performance regression. I posted the link in the bug description.
>>
>> Thanks,
>> Tobias
>>
>>
>> [1]
>> -- x86_64, Solaris --
>>
>> Baseline
>>    Score: 150.8 (+- 2.1)
>>    Compilation speed: 31548.7 bytes/s (+- 247.67)
>> Fix
>>    Score: 151.1 (+- 1.86)
>>    Compilaion speed: 31878.5 bytes/s (+- 195.88)
>>
>>
>> -- Sparc, Solaris --
>>
>> Baseline
>>    Score: 17.46 (+- 0.11)
>>    Compilation speed: 4342.5 (+- 55.32)
>> Fix
>>    Score: 17.4 (+- 0.13)
>>    Compilation speed: 4349.5 (+- 69.66)
>>
>>
>> The numbers in brackets show the 95% confidence interval.
>>
>>
>> On 15.05.2014 23:27, Vladimir Kozlov wrote:
>>> Tobias,
>>>
>>> Changes are fine but I am concern about compilation speed.
>>> Please, test compilation performance (-XX:+TimeCompiler) on x86 and 
>>> sparc. You need to build optimized VM for that to
>>> exclude assert but keep statistic code. I would suggest to run one 
>>> of nashorn octane benchmarks with -Xcomp
>>> -XX:-TieredCompilation to get compilation with big graphs.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 5/15/14 11:53 AM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> please review the following patch that removes the IDX_INIT macro used
>>>> by Node::Node(...) to retrieve the Compile object and replaces it by a
>>>> call to Compile::current(). The Node constructor, new operator and all
>>>> calls to it are adapted accordingly.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034812
>>>> Webrev: http://cr.openjdk.java.net/~anoll/8034812/webrev.00/
>>>>
>>>> Tested with JPRT.
>>>>
>>>> Thanks,
>>>> Tobias
>>


From tobias.hartmann at oracle.com  Wed May 28 09:28:47 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 28 May 2014 11:28:47 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <50984C6A-06C5-46F9-97DC-B5E37DBEE5CF@oracle.com>
References: <5374B6C1.5010903@oracle.com>
	<0B8543E3-B312-48F2-90C3-DB60A3063DE6@oracle.com>
	<5374BCEC.3000107@oracle.com>
	<A92D8AA7-071A-4077-A52E-55C62F2382B1@oracle.com>
	<5374C068.9010802@oracle.com>
	<E73480C9-3078-4EC4-B1AB-E2950E37A6EB@oracle.com>
	<5375F9A0.30106@oracle.com>
	<50984C6A-06C5-46F9-97DC-B5E37DBEE5CF@oracle.com>
Message-ID: <5385AC4F.1050905@oracle.com>

Hi Roland,

I updated the fix accordingly. Please find the new webrev at:

http://cr.openjdk.java.net/~anoll/8021775/webrev.01/

Thanks,
Tobias

On 16.05.2014 15:01, Roland Westrelin wrote:
> Hi Tobias,
>
>> Okay, I'm fine with changing the test to allow recursive calls to vary by 1. Should I then remove the usage of the Whitebox API?
> I?m ok with keeping the whitebox API.
>
> Roland.


From tobias.hartmann at oracle.com  Wed May 28 09:31:36 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 28 May 2014 11:31:36 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <D200E44A-EFEB-4772-A1DA-1B3FA6637D87@oracle.com>
References: <5374B6C1.5010903@oracle.com>
	<63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>
	<5375F6A3.3010307@oracle.com>
	<D200E44A-EFEB-4772-A1DA-1B3FA6637D87@oracle.com>
Message-ID: <5385ACF8.2020609@oracle.com>

Hi Chris,

thanks for the feedback.

On 16.05.2014 18:00, Christian Thalinger wrote:
>
> On May 16, 2014, at 4:29 AM, Tobias Hartmann 
> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>
>> Hi Chris,
>>
>> thanks for the review.
>>
>> On 15.05.2014 16:31, Christian Thalinger wrote:
>>> Presumably:
>>> *+          WHITE_BOX.enqueueMethodForCompilation(m3, COMP_LEVEL_FULL_OPTIMIZATION);*
>>> *+          if(!WHITE_BOX.isMethodCompiled(m3)) {*
>>> *+             throw new RuntimeException(m3 + " not compiled");*
>>>            }
>>> works because we?re using -XX:-BackgroundCompilation, correct? 
>>>  Maybe add a comment there. 
>>
>> Yes, exactly.
>>
>>>  Can we verify via WB API that BackgroundCompilation is off?
>>
>> Yes, this is for example done in 
>> CompilerWhiteBoxTest::getVMOption(...) to set BACKGROUND_COMPILATION. 
>> But I think because we explicitly disable background compilation in 
>> the test header it should not be possible to re-enable it, right?
>
> Correct but who knows what test cleanup might happen in the future. 
>  Maybe someday someone decides that we shouldn?t run tests with 
> -BackgroundCompilation.  This test is not easy to get right and had a 
> couple of issues already.  I want it fool proof.

Right. I added a method backgroundCompilationEnabled(...) to check if 
background compilation is enabled and explicitly check it in main.

New webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.01/

Thanks,
Tobias

>
>>
>> Thanks,
>> Tobias
>>
>>>
>>> I?m happy that using the WB API worked.
>>>
>>> On May 15, 2014, at 5:44 AM, Tobias Hartmann 
>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>>
>>>> Hi,
>>>>
>>>> please review the following patch for 8021775.
>>>>
>>>> *Problem
>>>> *The compiler test for bug 8009761 checks if the stack size after 
>>>> deoptimization is the same as before by counting the number of 
>>>> possible recursive calls until a StackOverflowException occurs both 
>>>> before and after deoptimization. The test tries to trigger 
>>>> compilation by executing the method multiple times and enforces 
>>>> deoptimization by loading a previously unloaded class.
>>>>
>>>> The test fails on multiple platforms.*
>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8021775
>>>>
>>>> *Solution**
>>>> *The test seems to be unstable, as there already occurred several 
>>>> test bugs (see 8010399 and 8012037). Enforcing compilation by 
>>>> executing a method multiple times is indeterministic. We have to 
>>>> make sure that the method is compiled and deoptimized exactly at 
>>>> those points in time where it is needed.
>>>>
>>>> I reimplemented the test using the Whitebox API to 
>>>> deterministically trigger compilation and deoptimization.
>>>> Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
>>>> *
>>>> **Tests*
>>>> Executed test on machines where it previously failed (1k runs, no 
>>>> fails).
>>>>
>>>> Thanks,
>>>> Tobias
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140528/12ebfd91/attachment-0001.html>

From igor.ignatyev at oracle.com  Wed May 28 10:32:43 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 28 May 2014 14:32:43 +0400
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5385ACF8.2020609@oracle.com>
References: <5374B6C1.5010903@oracle.com>	<63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>	<5375F6A3.3010307@oracle.com>	<D200E44A-EFEB-4772-A1DA-1B3FA6637D87@oracle.com>
	<5385ACF8.2020609@oracle.com>
Message-ID: <5385BB4B.2040903@oracle.com>

Hi Tobias,

Since now the test uses JMX, you have to add it into needs_compact3 
group in 'test/TEST.groups'.

Igor

On 05/28/2014 01:31 PM, Tobias Hartmann wrote:
> Hi Chris,
>
> thanks for the feedback.
>
> On 16.05.2014 18:00, Christian Thalinger wrote:
>>
>> On May 16, 2014, at 4:29 AM, Tobias Hartmann
>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>
>>> Hi Chris,
>>>
>>> thanks for the review.
>>>
>>> On 15.05.2014 16:31, Christian Thalinger wrote:
>>>> Presumably:
>>>> *+          WHITE_BOX.enqueueMethodForCompilation(m3, COMP_LEVEL_FULL_OPTIMIZATION);*
>>>> *+          if(!WHITE_BOX.isMethodCompiled(m3)) {*
>>>> *+             throw new RuntimeException(m3 + " not compiled");*
>>>>            }
>>>> works because we?re using -XX:-BackgroundCompilation, correct?
>>>>  Maybe add a comment there.
>>>
>>> Yes, exactly.
>>>
>>>>  Can we verify via WB API that BackgroundCompilation is off?
>>>
>>> Yes, this is for example done in
>>> CompilerWhiteBoxTest::getVMOption(...) to set BACKGROUND_COMPILATION.
>>> But I think because we explicitly disable background compilation in
>>> the test header it should not be possible to re-enable it, right?
>>
>> Correct but who knows what test cleanup might happen in the future.
>>  Maybe someday someone decides that we shouldn?t run tests with
>> -BackgroundCompilation.  This test is not easy to get right and had a
>> couple of issues already.  I want it fool proof.
>
> Right. I added a method backgroundCompilationEnabled(...) to check if
> background compilation is enabled and explicitly check it in main.
>
> New webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.01/
>
> Thanks,
> Tobias
>
>>
>>>
>>> Thanks,
>>> Tobias
>>>
>>>>
>>>> I?m happy that using the WB API worked.
>>>>
>>>> On May 15, 2014, at 5:44 AM, Tobias Hartmann
>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> please review the following patch for 8021775.
>>>>>
>>>>> *Problem
>>>>> *The compiler test for bug 8009761 checks if the stack size after
>>>>> deoptimization is the same as before by counting the number of
>>>>> possible recursive calls until a StackOverflowException occurs both
>>>>> before and after deoptimization. The test tries to trigger
>>>>> compilation by executing the method multiple times and enforces
>>>>> deoptimization by loading a previously unloaded class.
>>>>>
>>>>> The test fails on multiple platforms.*
>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8021775
>>>>>
>>>>> *Solution**
>>>>> *The test seems to be unstable, as there already occurred several
>>>>> test bugs (see 8010399 and 8012037). Enforcing compilation by
>>>>> executing a method multiple times is indeterministic. We have to
>>>>> make sure that the method is compiled and deoptimized exactly at
>>>>> those points in time where it is needed.
>>>>>
>>>>> I reimplemented the test using the Whitebox API to
>>>>> deterministically trigger compilation and deoptimization.
>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
>>>>> *
>>>>> **Tests*
>>>>> Executed test on machines where it previously failed (1k runs, no
>>>>> fails).
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>
>>>
>>
>

From tobias.hartmann at oracle.com  Wed May 28 10:45:44 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 28 May 2014 12:45:44 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5385BB4B.2040903@oracle.com>
References: <5374B6C1.5010903@oracle.com>	<63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>	<5375F6A3.3010307@oracle.com>	<D200E44A-EFEB-4772-A1DA-1B3FA6637D87@oracle.com>
	<5385ACF8.2020609@oracle.com> <5385BB4B.2040903@oracle.com>
Message-ID: <5385BE58.10303@oracle.com>

Hi Igor,

On 28.05.2014 12:32, Igor Ignatyev wrote:
> Hi Tobias,
>
> Since now the test uses JMX, you have to add it into needs_compact3 
> group in 'test/TEST.groups'.

Done. New webrev:

http://cr.openjdk.java.net/~anoll/8021775/webrev.02/

Thanks,
Tobias

>
>
> Igor
>
> On 05/28/2014 01:31 PM, Tobias Hartmann wrote:
>> Hi Chris,
>>
>> thanks for the feedback.
>>
>> On 16.05.2014 18:00, Christian Thalinger wrote:
>>>
>>> On May 16, 2014, at 4:29 AM, Tobias Hartmann
>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> thanks for the review.
>>>>
>>>> On 15.05.2014 16:31, Christian Thalinger wrote:
>>>>> Presumably:
>>>>> *+          WHITE_BOX.enqueueMethodForCompilation(m3, 
>>>>> COMP_LEVEL_FULL_OPTIMIZATION);*
>>>>> *+          if(!WHITE_BOX.isMethodCompiled(m3)) {*
>>>>> *+             throw new RuntimeException(m3 + " not compiled");*
>>>>>            }
>>>>> works because we?re using -XX:-BackgroundCompilation, correct?
>>>>>  Maybe add a comment there.
>>>>
>>>> Yes, exactly.
>>>>
>>>>>  Can we verify via WB API that BackgroundCompilation is off?
>>>>
>>>> Yes, this is for example done in
>>>> CompilerWhiteBoxTest::getVMOption(...) to set BACKGROUND_COMPILATION.
>>>> But I think because we explicitly disable background compilation in
>>>> the test header it should not be possible to re-enable it, right?
>>>
>>> Correct but who knows what test cleanup might happen in the future.
>>>  Maybe someday someone decides that we shouldn?t run tests with
>>> -BackgroundCompilation.  This test is not easy to get right and had a
>>> couple of issues already.  I want it fool proof.
>>
>> Right. I added a method backgroundCompilationEnabled(...) to check if
>> background compilation is enabled and explicitly check it in main.
>>
>> New webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.01/
>>
>> Thanks,
>> Tobias
>>
>>>
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>>
>>>>> I?m happy that using the WB API worked.
>>>>>
>>>>> On May 15, 2014, at 5:44 AM, Tobias Hartmann
>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> please review the following patch for 8021775.
>>>>>>
>>>>>> *Problem
>>>>>> *The compiler test for bug 8009761 checks if the stack size after
>>>>>> deoptimization is the same as before by counting the number of
>>>>>> possible recursive calls until a StackOverflowException occurs both
>>>>>> before and after deoptimization. The test tries to trigger
>>>>>> compilation by executing the method multiple times and enforces
>>>>>> deoptimization by loading a previously unloaded class.
>>>>>>
>>>>>> The test fails on multiple platforms.*
>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8021775
>>>>>>
>>>>>> *Solution**
>>>>>> *The test seems to be unstable, as there already occurred several
>>>>>> test bugs (see 8010399 and 8012037). Enforcing compilation by
>>>>>> executing a method multiple times is indeterministic. We have to
>>>>>> make sure that the method is compiled and deoptimized exactly at
>>>>>> those points in time where it is needed.
>>>>>>
>>>>>> I reimplemented the test using the Whitebox API to
>>>>>> deterministically trigger compilation and deoptimization.
>>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
>>>>>> *
>>>>>> **Tests*
>>>>>> Executed test on machines where it previously failed (1k runs, no
>>>>>> fails).
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>
>>>>
>>>
>>


From igor.ignatyev at oracle.com  Wed May 28 10:54:39 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 28 May 2014 14:54:39 +0400
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5385BE58.10303@oracle.com>
References: <5374B6C1.5010903@oracle.com>	<63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>	<5375F6A3.3010307@oracle.com>	<D200E44A-EFEB-4772-A1DA-1B3FA6637D87@oracle.com>
	<5385ACF8.2020609@oracle.com> <5385BB4B.2040903@oracle.com>
	<5385BE58.10303@oracle.com>
Message-ID: <5385C06F.5090408@oracle.com>

Thanks.

Could you please also replace System::exit by throwing an exception?
>  277             System.exit(97);

Igor

On 05/28/2014 02:45 PM, Tobias Hartmann wrote:
> Hi Igor,
>
> On 28.05.2014 12:32, Igor Ignatyev wrote:
>> Hi Tobias,
>>
>> Since now the test uses JMX, you have to add it into needs_compact3
>> group in 'test/TEST.groups'.
>
> Done. New webrev:
>
> http://cr.openjdk.java.net/~anoll/8021775/webrev.02/
>
> Thanks,
> Tobias
>
>>
>>
>> Igor
>>
>> On 05/28/2014 01:31 PM, Tobias Hartmann wrote:
>>> Hi Chris,
>>>
>>> thanks for the feedback.
>>>
>>> On 16.05.2014 18:00, Christian Thalinger wrote:
>>>>
>>>> On May 16, 2014, at 4:29 AM, Tobias Hartmann
>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> thanks for the review.
>>>>>
>>>>> On 15.05.2014 16:31, Christian Thalinger wrote:
>>>>>> Presumably:
>>>>>> *+          WHITE_BOX.enqueueMethodForCompilation(m3,
>>>>>> COMP_LEVEL_FULL_OPTIMIZATION);*
>>>>>> *+          if(!WHITE_BOX.isMethodCompiled(m3)) {*
>>>>>> *+             throw new RuntimeException(m3 + " not compiled");*
>>>>>>            }
>>>>>> works because we?re using -XX:-BackgroundCompilation, correct?
>>>>>>  Maybe add a comment there.
>>>>>
>>>>> Yes, exactly.
>>>>>
>>>>>>  Can we verify via WB API that BackgroundCompilation is off?
>>>>>
>>>>> Yes, this is for example done in
>>>>> CompilerWhiteBoxTest::getVMOption(...) to set BACKGROUND_COMPILATION.
>>>>> But I think because we explicitly disable background compilation in
>>>>> the test header it should not be possible to re-enable it, right?
>>>>
>>>> Correct but who knows what test cleanup might happen in the future.
>>>>  Maybe someday someone decides that we shouldn?t run tests with
>>>> -BackgroundCompilation.  This test is not easy to get right and had a
>>>> couple of issues already.  I want it fool proof.
>>>
>>> Right. I added a method backgroundCompilationEnabled(...) to check if
>>> background compilation is enabled and explicitly check it in main.
>>>
>>> New webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.01/
>>>
>>> Thanks,
>>> Tobias
>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>>>>
>>>>>> I?m happy that using the WB API worked.
>>>>>>
>>>>>> On May 15, 2014, at 5:44 AM, Tobias Hartmann
>>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> please review the following patch for 8021775.
>>>>>>>
>>>>>>> *Problem
>>>>>>> *The compiler test for bug 8009761 checks if the stack size after
>>>>>>> deoptimization is the same as before by counting the number of
>>>>>>> possible recursive calls until a StackOverflowException occurs both
>>>>>>> before and after deoptimization. The test tries to trigger
>>>>>>> compilation by executing the method multiple times and enforces
>>>>>>> deoptimization by loading a previously unloaded class.
>>>>>>>
>>>>>>> The test fails on multiple platforms.*
>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8021775
>>>>>>>
>>>>>>> *Solution**
>>>>>>> *The test seems to be unstable, as there already occurred several
>>>>>>> test bugs (see 8010399 and 8012037). Enforcing compilation by
>>>>>>> executing a method multiple times is indeterministic. We have to
>>>>>>> make sure that the method is compiled and deoptimized exactly at
>>>>>>> those points in time where it is needed.
>>>>>>>
>>>>>>> I reimplemented the test using the Whitebox API to
>>>>>>> deterministically trigger compilation and deoptimization.
>>>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
>>>>>>> *
>>>>>>> **Tests*
>>>>>>> Executed test on machines where it previously failed (1k runs, no
>>>>>>> fails).
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>
>>>>>
>>>>
>>>
>

From tobias.hartmann at oracle.com  Wed May 28 11:02:28 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 28 May 2014 13:02:28 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5385C06F.5090408@oracle.com>
References: <5374B6C1.5010903@oracle.com>	<63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>	<5375F6A3.3010307@oracle.com>	<D200E44A-EFEB-4772-A1DA-1B3FA6637D87@oracle.com>
	<5385ACF8.2020609@oracle.com> <5385BB4B.2040903@oracle.com>
	<5385BE58.10303@oracle.com> <5385C06F.5090408@oracle.com>
Message-ID: <5385C244.4010901@oracle.com>


On 28.05.2014 12:54, Igor Ignatyev wrote:
> Thanks.
>
> Could you please also replace System::exit by throwing an exception?
>>  277             System.exit(97);
>
Done:

http://cr.openjdk.java.net/~anoll/8021775/webrev.03/

Thanks,
Tobias

> Igor
>
> On 05/28/2014 02:45 PM, Tobias Hartmann wrote:
>> Hi Igor,
>>
>> On 28.05.2014 12:32, Igor Ignatyev wrote:
>>> Hi Tobias,
>>>
>>> Since now the test uses JMX, you have to add it into needs_compact3
>>> group in 'test/TEST.groups'.
>>
>> Done. New webrev:
>>
>> http://cr.openjdk.java.net/~anoll/8021775/webrev.02/
>>
>> Thanks,
>> Tobias
>>
>>>
>>>
>>> Igor
>>>
>>> On 05/28/2014 01:31 PM, Tobias Hartmann wrote:
>>>> Hi Chris,
>>>>
>>>> thanks for the feedback.
>>>>
>>>> On 16.05.2014 18:00, Christian Thalinger wrote:
>>>>>
>>>>> On May 16, 2014, at 4:29 AM, Tobias Hartmann
>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> 
>>>>> wrote:
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> thanks for the review.
>>>>>>
>>>>>> On 15.05.2014 16:31, Christian Thalinger wrote:
>>>>>>> Presumably:
>>>>>>> *+          WHITE_BOX.enqueueMethodForCompilation(m3,
>>>>>>> COMP_LEVEL_FULL_OPTIMIZATION);*
>>>>>>> *+          if(!WHITE_BOX.isMethodCompiled(m3)) {*
>>>>>>> *+             throw new RuntimeException(m3 + " not compiled");*
>>>>>>>            }
>>>>>>> works because we?re using -XX:-BackgroundCompilation, correct?
>>>>>>>  Maybe add a comment there.
>>>>>>
>>>>>> Yes, exactly.
>>>>>>
>>>>>>>  Can we verify via WB API that BackgroundCompilation is off?
>>>>>>
>>>>>> Yes, this is for example done in
>>>>>> CompilerWhiteBoxTest::getVMOption(...) to set 
>>>>>> BACKGROUND_COMPILATION.
>>>>>> But I think because we explicitly disable background compilation in
>>>>>> the test header it should not be possible to re-enable it, right?
>>>>>
>>>>> Correct but who knows what test cleanup might happen in the future.
>>>>>  Maybe someday someone decides that we shouldn?t run tests with
>>>>> -BackgroundCompilation.  This test is not easy to get right and had a
>>>>> couple of issues already.  I want it fool proof.
>>>>
>>>> Right. I added a method backgroundCompilationEnabled(...) to check if
>>>> background compilation is enabled and explicitly check it in main.
>>>>
>>>> New webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.01/
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>>>
>>>>>>> I?m happy that using the WB API worked.
>>>>>>>
>>>>>>> On May 15, 2014, at 5:44 AM, Tobias Hartmann
>>>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> please review the following patch for 8021775.
>>>>>>>>
>>>>>>>> *Problem
>>>>>>>> *The compiler test for bug 8009761 checks if the stack size after
>>>>>>>> deoptimization is the same as before by counting the number of
>>>>>>>> possible recursive calls until a StackOverflowException occurs 
>>>>>>>> both
>>>>>>>> before and after deoptimization. The test tries to trigger
>>>>>>>> compilation by executing the method multiple times and enforces
>>>>>>>> deoptimization by loading a previously unloaded class.
>>>>>>>>
>>>>>>>> The test fails on multiple platforms.*
>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8021775
>>>>>>>>
>>>>>>>> *Solution**
>>>>>>>> *The test seems to be unstable, as there already occurred several
>>>>>>>> test bugs (see 8010399 and 8012037). Enforcing compilation by
>>>>>>>> executing a method multiple times is indeterministic. We have to
>>>>>>>> make sure that the method is compiled and deoptimized exactly at
>>>>>>>> those points in time where it is needed.
>>>>>>>>
>>>>>>>> I reimplemented the test using the Whitebox API to
>>>>>>>> deterministically trigger compilation and deoptimization.
>>>>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
>>>>>>>> *
>>>>>>>> **Tests*
>>>>>>>> Executed test on machines where it previously failed (1k runs, no
>>>>>>>> fails).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>
>>>>>>
>>>>>
>>>>
>>


From igor.ignatyev at oracle.com  Wed May 28 11:43:41 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 28 May 2014 15:43:41 +0400
Subject: RFR(XXS) : 8043899: compiler/5091921/Test7005594.java fails if
	specified -Xmx is less than 1600m
In-Reply-To: <538342F9.2090202@oracle.com>
References: <538342F9.2090202@oracle.com>
Message-ID: <5385CBED.2040908@oracle.com>

VladimirK, Chris, VladimirI,

Thank you for review.

Igor

On 05/26/2014 05:34 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8043899/webrev.00/
> 3 lines changed: 0 ins; 1 del; 2 mod;
>
> Hi all,
>
> Please review patch:
>
> Problem:
> - the test specifies '-Xms' equal to 1600m. so it will fail, if the
> harness passes '-Xmx' which is less than 1600m.
> - 8015007 changed the error message in Universe::reserve_heap()
>>     946   if (!total_rs.is_reserved()) {
>>     947     vm_exit_during_initialization(err_msg("Could not reserve
>> enough space for " SIZE_FORMAT "KB object heap", total_reserved/K));
>>     948     return total_rs;
>>     949   }
> the test treats this message as a failure.
>
> Fix:
> - set Xmx to 1600m
> - change the pattern of allowable error message
>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8043899
> testing: failing tests in jprt

From roland.westrelin at oracle.com  Wed May 28 13:45:11 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 28 May 2014 15:45:11 +0200
Subject: RFR(XS): 8044090: C1: Old value instead of new one is passed to
	post-barrier in UnsafeGetAndSetObject
In-Reply-To: <F98F5E3F-8CE2-4F22-BA61-D6714C417B1E@oracle.com>
References: <F98F5E3F-8CE2-4F22-BA61-D6714C417B1E@oracle.com>
Message-ID: <AF537005-81AC-42FD-8B33-4499ACBF882F@oracle.com>

> Webrev: http://cr.openjdk.java.net/~iveresov/8044090/webrev.00/

That looks good to me.

Roland.

From roland.westrelin at oracle.com  Wed May 28 13:52:54 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 28 May 2014 15:52:54 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5385C244.4010901@oracle.com>
References: <5374B6C1.5010903@oracle.com>	<63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>	<5375F6A3.3010307@oracle.com>	<D200E44A-EFEB-4772-A1DA-1B3FA6637D87@oracle.com>
	<5385ACF8.2020609@oracle.com> <5385BB4B.2040903@oracle.com>
	<5385BE58.10303@oracle.com> <5385C06F.5090408@oracle.com>
	<5385C244.4010901@oracle.com>
Message-ID: <1514C202-60CA-4FCC-9327-E7CCE56744FC@oracle.com>

> http://cr.openjdk.java.net/~anoll/8021775/webrev.03/

That looks good to me.

Roland.

From yekaterina.kantserova at oracle.com  Wed May 28 11:58:35 2014
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 28 May 2014 13:58:35 +0200
Subject: RFR(S): 8043915: Tests get ClassNotFoundException:
	com.oracle.java.testlibrary.StreamPumper
Message-ID: <5385CF6B.3090404@oracle.com>

Hi,

Could I please have a review of this fix.

webrev: http://cr.openjdk.java.net/~ykantser/8043915/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8043915

When using @library in a JTreg test even @build need to be specify for 
all library files used by the test. If @build is not specified it can 
lead to intermittent failures when for example running tests 
concurrently, since javac implicit compilation and @library and 
-concurrency don't play well together.

Verified locally.

Thanks,
Katja

From vladimir.x.ivanov at oracle.com  Wed May 28 15:04:34 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 28 May 2014 19:04:34 +0400
Subject: RFR(XS): 8044090: C1: Old value instead of new one is passed
	to post-barrier in UnsafeGetAndSetObject
In-Reply-To: <F98F5E3F-8CE2-4F22-BA61-D6714C417B1E@oracle.com>
References: <F98F5E3F-8CE2-4F22-BA61-D6714C417B1E@oracle.com>
Message-ID: <5385FB02.8050507@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 5/28/14 10:38 AM, Igor Veresov wrote:
> I didn?t notice this before but in UnsafeGetAndSetObject on C1 SPARC we?re passing an old value (which we are getting as a result of the xchg) to the post-barrier, while it really expect the new value (what was stored into memory).
>
> Webrev: http://cr.openjdk.java.net/~iveresov/8044090/webrev.00/
>
> Thanks!
> igor
>

From mikael.vidstedt at oracle.com  Wed May 28 16:17:04 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Wed, 28 May 2014 09:17:04 -0700
Subject: RFR (XS): 8043207: Add const to Address argument for Assembler::swap
Message-ID: <53860C00.2010604@oracle.com>


Please review the following fix which changes one of the Assembler::swap 
methods to take a *const* Address argument instead of a non-const. Some 
of the usages of the swap method pass a const argument, and when 
compiling with gcc the const-ness mismatch means the method cannot be 
resolved which in turn means a compilation error. This is for jdk7u 
(only) - the relevant code has been rewritten in jdk8+ to no longer have 
this problem.

Bug: https://bugs.openjdk.java.net/browse/JDK-8043207
Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8043207/webrev.00/webrev/

Thanks,
Mikael


From vladimir.x.ivanov at oracle.com  Wed May 28 16:37:13 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 28 May 2014 20:37:13 +0400
Subject: Regarding 8033626: C2: Merging exception state: reexecute=true vs
	reexecute=false
Message-ID: <538610B9.6060008@oracle.com>

Hi,

I'm looking at 8033626 [1]: 
"assert(ex_map->jvms()->same_calls_as(_exceptions->jvms())) failed: all 
collected exceptions must come from the same place".

8014447 [2] introduced new code shape for virtual intrinsifiable methods 
(Object::hashCode & Object::clone): "invokevirtual Object.clone()" can 
be represented as a PredictedCallGenerator with LibraryIntrinsic on fast 
path and VirtualCallGenerator on slow path.

The problem arises for Object::clone, because for OOM case intrinsified 
version requires reexecution (reexecute=true), but slow path (virtual 
dispatch) doesn't (reexecute=false). Further attempt to finish the 
diamond and merge 2 exception states fires the assertion.

So, I have 2 questions:
   (1) I don't see any way to merge reexecute=true & reexecute=false 
states, so both branches should have the same reexecute status. Am I 
missing something?

   (2) Does PredictedCallGenerator actually support such shape 
(intrinsic on fast path)? There are 2 call generators: 
PredictedIntrinsicGenerator & PredictedCallGenerator. What's the 
difference?

I see there's a way to customize predicate in 
LibraryCallKit::try_to_predicate() for PredictedIntrinsicGenerator, but 
is it the only reason why PredictedIntrinsicGenerator was introduced?

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8033626

[2] https://bugs.openjdk.java.net/browse/JDK-8014447
     "Object.hashCode intrinsic breaks inline caches"

From vladimir.kozlov at oracle.com  Wed May 28 17:23:48 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 28 May 2014 10:23:48 -0700
Subject: RFR (XS): 8043207: Add const to Address argument for
	Assembler::swap
In-Reply-To: <53860C00.2010604@oracle.com>
References: <53860C00.2010604@oracle.com>
Message-ID: <53861BA4.6030602@oracle.com>

Good.

Vladimir

On 5/28/14 9:17 AM, Mikael Vidstedt wrote:
>
> Please review the following fix which changes one of the Assembler::swap methods to take a *const* Address argument
> instead of a non-const. Some of the usages of the swap method pass a const argument, and when compiling with gcc the
> const-ness mismatch means the method cannot be resolved which in turn means a compilation error. This is for jdk7u
> (only) - the relevant code has been rewritten in jdk8+ to no longer have this problem.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8043207
> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8043207/webrev.00/webrev/
>
> Thanks,
> Mikael
>

From igor.veresov at oracle.com  Wed May 28 17:44:41 2014
From: igor.veresov at oracle.com (Igor Veresov)
Date: Wed, 28 May 2014 07:44:41 -1000
Subject: RFR(XS): 8044090: C1: Old value instead of new one is passed to
	post-barrier in UnsafeGetAndSetObject
In-Reply-To: <5385FB02.8050507@oracle.com>
References: <F98F5E3F-8CE2-4F22-BA61-D6714C417B1E@oracle.com>
	<5385FB02.8050507@oracle.com>
Message-ID: <2148F057-F1BF-475F-9BC9-3221AB630114@oracle.com>

Thanks Roland and Vladimir!

igor

On May 28, 2014, at 5:04 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Looks good.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 5/28/14 10:38 AM, Igor Veresov wrote:
>> I didn?t notice this before but in UnsafeGetAndSetObject on C1 SPARC we?re passing an old value (which we are getting as a result of the xchg) to the post-barrier, while it really expect the new value (what was stored into memory).
>> 
>> Webrev: http://cr.openjdk.java.net/~iveresov/8044090/webrev.00/
>> 
>> Thanks!
>> igor
>> 


From albert.noll at oracle.com  Wed May 28 19:16:46 2014
From: albert.noll at oracle.com (Albert)
Date: Wed, 28 May 2014 21:16:46 +0200
Subject: [8u20,
	9] RFR(S): 8011646	: SEGV in compiled code with loop predication
Message-ID: <5386361E.8020903@oracle.com>

Hi,

could I get reviews for this small patch?

Bug:
https://bugs.openjdk.java.net/browse/JDK-8011646

Problem:
LibraryCallKit::inline_native_hashcode() uses a control input to the 
load node 'n' that loads the header.
'n' is connected to a castPP node, which maintains the dependency 
between the null check of 'n' and 'n'.
A later compiler phase removes this castPP. The dependency between the 
null check and 'n' is lost if
the 'n' has a control input (see MemNode::Ideal_common_DU_postCCP() ). 
The reason for the
lost dependency is that loop predication erroneously sets the control 
edge of the load to a predicate
that is hoisted out of the loop.
If, however, the load has no control edge, 
MemNode::Ideal_common_DU_postCCP() sets the control edge
correctly. This

The bug description contains a Java program that reproduces this 
behavior. Also, the bug description contains
a graph that can be viewed with the IGV. For example, the LoadL node 
(830) in Phase "After Parsing" has a
control edge that is connected to node 780. At the phase, the graph is 
still correct. In phase "InterGVN 2"
the control edge is connected to a node outside the loop. As a result, 
the dependency between the null
check and the load is lost.

Solution:
Do not add a control input to the load. As a result, the control to the 
load is set correctly when the castPP node
is removed.

Webrev:
http://cr.openjdk.java.net/~anoll/8011646/webrev.00/

Testing:
Failing test case, regression test, jprt



Many thanks to Roland and Vladimir who helped me a lot with this bug.

Best,
Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140528/e9dbbc0e/attachment-0001.html>

From vladimir.kozlov at oracle.com  Wed May 28 19:45:54 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 28 May 2014 12:45:54 -0700
Subject: [8u20,
	9] RFR(S): 8011646	: SEGV in compiled code with loop predication
In-Reply-To: <5386361E.8020903@oracle.com>
References: <5386361E.8020903@oracle.com>
Message-ID: <53863CF2.9040406@oracle.com>

Good. Thank you, Albert.

Vladimir

On 5/28/14 12:16 PM, Albert wrote:
> Hi,
>
> could I get reviews for this small patch?
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8011646
>
> Problem:
> LibraryCallKit::inline_native_hashcode() uses a control input to the
> load node 'n' that loads the header.
> 'n' is connected to a castPP node, which maintains the dependency
> between the null check of 'n' and 'n'.
> A later compiler phase removes this castPP. The dependency between the
> null check and 'n' is lost if
> the 'n' has a control input (see MemNode::Ideal_common_DU_postCCP() ).
> The reason for the
> lost dependency is that loop predication erroneously sets the control
> edge of the load to a predicate
> that is hoisted out of the loop.
> If, however, the load has no control edge,
> MemNode::Ideal_common_DU_postCCP() sets the control edge
> correctly. This
>
> The bug description contains a Java program that reproduces this
> behavior. Also, the bug description contains
> a graph that can be viewed with the IGV. For example, the LoadL node
> (830) in Phase "After Parsing" has a
> control edge that is connected to node 780. At the phase, the graph is
> still correct. In phase "InterGVN 2"
> the control edge is connected to a node outside the loop. As a result,
> the dependency between the null
> check and the load is lost.
>
> Solution:
> Do not add a control input to the load. As a result, the control to the
> load is set correctly when the castPP node
> is removed.
>
> Webrev:
> http://cr.openjdk.java.net/~anoll/8011646/webrev.00/
>
> Testing:
> Failing test case, regression test, jprt
>
>
>
> Many thanks to Roland and Vladimir who helped me a lot with this bug.
>
> Best,
> Albert

From roland.westrelin at oracle.com  Wed May 28 20:42:34 2014
From: roland.westrelin at oracle.com (Roland Westrelin)
Date: Wed, 28 May 2014 22:42:34 +0200
Subject: [8u20,
	9] RFR(S): 8011646	: SEGV in compiled code with loop predication
In-Reply-To: <5386361E.8020903@oracle.com>
References: <5386361E.8020903@oracle.com>
Message-ID: <9401C93A-028E-40D5-BBBA-85B2B61CD73A@oracle.com>

> http://cr.openjdk.java.net/~anoll/8011646/webrev.00/

That looks good to me.

Is anything changed in those lines?

4046   Node* lock_mask      = _gvn.MakeConX(markOopDesc::biased_lock_mask_in_place);
4047   Node* lmasked_header = _gvn.transform(new (C) AndXNode(header, lock_mask));
4048   Node* unlocked_val   = _gvn.MakeConX(markOopDesc::unlocked_value);
4049   Node* chk_unlocked   = _gvn.transform(new (C) CmpXNode( lmasked_header, unlocked_val));
4050   Node* test_unlocked  = _gvn.transform(new (C) BoolNode( chk_unlocked, BoolTest::ne));

4058   Node* hash_mask      = _gvn.intcon(markOopDesc::hash_mask);
4059   Node* hash_shift     = _gvn.intcon(markOopDesc::hash_shift);
4060   Node* hshifted_header= _gvn.transform(new (C) URShiftXNode(header, hash_shift));

4066   Node* hash_val       = _gvn.transform(new (C) AndINode(hshifted_header, hash_mask));

4068   Node* no_hash_val    = _gvn.intcon(markOopDesc::no_hash);
4069   Node* chk_assigned   = _gvn.transform(new (C) CmpINode( hash_val, no_hash_val));
4070   Node* test_assigned  = _gvn.transform(new (C) BoolNode( chk_assigned, BoolTest::eq));

Roland.

From christian.thalinger at oracle.com  Wed May 28 20:49:43 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 28 May 2014 13:49:43 -0700
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <5385C244.4010901@oracle.com>
References: <5374B6C1.5010903@oracle.com>	<63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>	<5375F6A3.3010307@oracle.com>	<D200E44A-EFEB-4772-A1DA-1B3FA6637D87@oracle.com>
	<5385ACF8.2020609@oracle.com> <5385BB4B.2040903@oracle.com>
	<5385BE58.10303@oracle.com> <5385C06F.5090408@oracle.com>
	<5385C244.4010901@oracle.com>
Message-ID: <BED42C73-3891-4B95-9495-0FE1D5FB39A2@oracle.com>

Looks good.  Thanks!

On May 28, 2014, at 4:02 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:

> 
> On 28.05.2014 12:54, Igor Ignatyev wrote:
>> Thanks.
>> 
>> Could you please also replace System::exit by throwing an exception?
>>> 277             System.exit(97);
>> 
> Done:
> 
> http://cr.openjdk.java.net/~anoll/8021775/webrev.03/
> 
> Thanks,
> Tobias
> 
>> Igor
>> 
>> On 05/28/2014 02:45 PM, Tobias Hartmann wrote:
>>> Hi Igor,
>>> 
>>> On 28.05.2014 12:32, Igor Ignatyev wrote:
>>>> Hi Tobias,
>>>> 
>>>> Since now the test uses JMX, you have to add it into needs_compact3
>>>> group in 'test/TEST.groups'.
>>> 
>>> Done. New webrev:
>>> 
>>> http://cr.openjdk.java.net/~anoll/8021775/webrev.02/
>>> 
>>> Thanks,
>>> Tobias
>>> 
>>>> 
>>>> 
>>>> Igor
>>>> 
>>>> On 05/28/2014 01:31 PM, Tobias Hartmann wrote:
>>>>> Hi Chris,
>>>>> 
>>>>> thanks for the feedback.
>>>>> 
>>>>> On 16.05.2014 18:00, Christian Thalinger wrote:
>>>>>> 
>>>>>> On May 16, 2014, at 4:29 AM, Tobias Hartmann
>>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>>>>> 
>>>>>>> Hi Chris,
>>>>>>> 
>>>>>>> thanks for the review.
>>>>>>> 
>>>>>>> On 15.05.2014 16:31, Christian Thalinger wrote:
>>>>>>>> Presumably:
>>>>>>>> *+          WHITE_BOX.enqueueMethodForCompilation(m3,
>>>>>>>> COMP_LEVEL_FULL_OPTIMIZATION);*
>>>>>>>> *+          if(!WHITE_BOX.isMethodCompiled(m3)) {*
>>>>>>>> *+             throw new RuntimeException(m3 + " not compiled");*
>>>>>>>>           }
>>>>>>>> works because we?re using -XX:-BackgroundCompilation, correct?
>>>>>>>> Maybe add a comment there.
>>>>>>> 
>>>>>>> Yes, exactly.
>>>>>>> 
>>>>>>>> Can we verify via WB API that BackgroundCompilation is off?
>>>>>>> 
>>>>>>> Yes, this is for example done in
>>>>>>> CompilerWhiteBoxTest::getVMOption(...) to set BACKGROUND_COMPILATION.
>>>>>>> But I think because we explicitly disable background compilation in
>>>>>>> the test header it should not be possible to re-enable it, right?
>>>>>> 
>>>>>> Correct but who knows what test cleanup might happen in the future.
>>>>>> Maybe someday someone decides that we shouldn?t run tests with
>>>>>> -BackgroundCompilation.  This test is not easy to get right and had a
>>>>>> couple of issues already.  I want it fool proof.
>>>>> 
>>>>> Right. I added a method backgroundCompilationEnabled(...) to check if
>>>>> background compilation is enabled and explicitly check it in main.
>>>>> 
>>>>> New webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.01/
>>>>> 
>>>>> Thanks,
>>>>> Tobias
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>> 
>>>>>>>> 
>>>>>>>> I?m happy that using the WB API worked.
>>>>>>>> 
>>>>>>>> On May 15, 2014, at 5:44 AM, Tobias Hartmann
>>>>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> please review the following patch for 8021775.
>>>>>>>>> 
>>>>>>>>> *Problem
>>>>>>>>> *The compiler test for bug 8009761 checks if the stack size after
>>>>>>>>> deoptimization is the same as before by counting the number of
>>>>>>>>> possible recursive calls until a StackOverflowException occurs both
>>>>>>>>> before and after deoptimization. The test tries to trigger
>>>>>>>>> compilation by executing the method multiple times and enforces
>>>>>>>>> deoptimization by loading a previously unloaded class.
>>>>>>>>> 
>>>>>>>>> The test fails on multiple platforms.*
>>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8021775
>>>>>>>>> 
>>>>>>>>> *Solution**
>>>>>>>>> *The test seems to be unstable, as there already occurred several
>>>>>>>>> test bugs (see 8010399 and 8012037). Enforcing compilation by
>>>>>>>>> executing a method multiple times is indeterministic. We have to
>>>>>>>>> make sure that the method is compiled and deoptimized exactly at
>>>>>>>>> those points in time where it is needed.
>>>>>>>>> 
>>>>>>>>> I reimplemented the test using the Whitebox API to
>>>>>>>>> deterministically trigger compilation and deoptimization.
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
>>>>>>>>> *
>>>>>>>>> **Tests*
>>>>>>>>> Executed test on machines where it previously failed (1k runs, no
>>>>>>>>> fails).
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Tobias
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
> 


From vladimir.kozlov at oracle.com  Wed May 28 21:40:33 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 28 May 2014 14:40:33 -0700
Subject: [8u20,
	9] RFR(S): 8011646	: SEGV in compiled code with loop predication
In-Reply-To: <9401C93A-028E-40D5-BBBA-85B2B61CD73A@oracle.com>
References: <5386361E.8020903@oracle.com>
	<9401C93A-028E-40D5-BBBA-85B2B61CD73A@oracle.com>
Message-ID: <538657D1.3020706@oracle.com>

On 5/28/14 1:42 PM, Roland Westrelin wrote:
>> http://cr.openjdk.java.net/~anoll/8011646/webrev.00/
>
> That looks good to me.
>
> Is anything changed in those lines?

It is only 'Node *' to 'Node* ' change. 'udiffs' show that cleanly.

Vladimir

>
> 4046   Node* lock_mask      = _gvn.MakeConX(markOopDesc::biased_lock_mask_in_place);
> 4047   Node* lmasked_header = _gvn.transform(new (C) AndXNode(header, lock_mask));
> 4048   Node* unlocked_val   = _gvn.MakeConX(markOopDesc::unlocked_value);
> 4049   Node* chk_unlocked   = _gvn.transform(new (C) CmpXNode( lmasked_header, unlocked_val));
> 4050   Node* test_unlocked  = _gvn.transform(new (C) BoolNode( chk_unlocked, BoolTest::ne));
>
> 4058   Node* hash_mask      = _gvn.intcon(markOopDesc::hash_mask);
> 4059   Node* hash_shift     = _gvn.intcon(markOopDesc::hash_shift);
> 4060   Node* hshifted_header= _gvn.transform(new (C) URShiftXNode(header, hash_shift));
>
> 4066   Node* hash_val       = _gvn.transform(new (C) AndINode(hshifted_header, hash_mask));
>
> 4068   Node* no_hash_val    = _gvn.intcon(markOopDesc::no_hash);
> 4069   Node* chk_assigned   = _gvn.transform(new (C) CmpINode( hash_val, no_hash_val));
> 4070   Node* test_assigned  = _gvn.transform(new (C) BoolNode( chk_assigned, BoolTest::eq));
>
> Roland.
>

From albert.noll at oracle.com  Wed May 28 21:53:30 2014
From: albert.noll at oracle.com (Albert)
Date: Wed, 28 May 2014 23:53:30 +0200
Subject: [8u20,
	9] RFR(S): 8011646	: SEGV in compiled code with loop predication
In-Reply-To: <538657D1.3020706@oracle.com>
References: <5386361E.8020903@oracle.com>	<9401C93A-028E-40D5-BBBA-85B2B61CD73A@oracle.com>
	<538657D1.3020706@oracle.com>
Message-ID: <53865ADA.7070208@oracle.com>

Vladimir, Roland, thanks for looking at this.

Best,
Albert
On 05/28/2014 11:40 PM, Vladimir Kozlov wrote:
> On 5/28/14 1:42 PM, Roland Westrelin wrote:
>>> http://cr.openjdk.java.net/~anoll/8011646/webrev.00/
>>
>> That looks good to me.
>>
>> Is anything changed in those lines?
>
> It is only 'Node *' to 'Node* ' change. 'udiffs' show that cleanly.
>
Yes, I just put the '*' uniformly to the left side.

> Vladimir
>
>>
>> 4046   Node* lock_mask      = 
>> _gvn.MakeConX(markOopDesc::biased_lock_mask_in_place);
>> 4047   Node* lmasked_header = _gvn.transform(new (C) AndXNode(header, 
>> lock_mask));
>> 4048   Node* unlocked_val   = 
>> _gvn.MakeConX(markOopDesc::unlocked_value);
>> 4049   Node* chk_unlocked   = _gvn.transform(new (C) CmpXNode( 
>> lmasked_header, unlocked_val));
>> 4050   Node* test_unlocked  = _gvn.transform(new (C) BoolNode( 
>> chk_unlocked, BoolTest::ne));
>>
>> 4058   Node* hash_mask      = _gvn.intcon(markOopDesc::hash_mask);
>> 4059   Node* hash_shift     = _gvn.intcon(markOopDesc::hash_shift);
>> 4060   Node* hshifted_header= _gvn.transform(new (C) 
>> URShiftXNode(header, hash_shift));
>>
>> 4066   Node* hash_val       = _gvn.transform(new (C) 
>> AndINode(hshifted_header, hash_mask));
>>
>> 4068   Node* no_hash_val    = _gvn.intcon(markOopDesc::no_hash);
>> 4069   Node* chk_assigned   = _gvn.transform(new (C) CmpINode( 
>> hash_val, no_hash_val));
>> 4070   Node* test_assigned  = _gvn.transform(new (C) BoolNode( 
>> chk_assigned, BoolTest::eq));
>>
>> Roland.
>>


From vladimir.kozlov at oracle.com  Wed May 28 22:18:07 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 28 May 2014 15:18:07 -0700
Subject: Regarding 8033626: C2: Merging exception state: reexecute=true
	vs reexecute=false
In-Reply-To: <538610B9.6060008@oracle.com>
References: <538610B9.6060008@oracle.com>
Message-ID: <5386609F.7030206@oracle.com>

PredictedIntrinsicGenerator was added to have a general predicate. For 
example, AES crypto predicate checks klass of an object pointed by a 
field. PredictedCallGenerator checks klass of method's holder only.

Both cases would have the same problem with reexecute. Using 
PredictedIntrinsicGenerator will not help you.

But you should not have this problem at the merge point, because 
reexecute should be reset back after intrinsic is generated:

   { PreserveReexecuteState preexecs(this);
     jvms()->set_should_reexecute(true);

It is strange that it is still true after PreserveReexecuteState destructor.

Vladimir K

On 5/28/14 9:37 AM, Vladimir Ivanov wrote:
> Hi,
>
> I'm looking at 8033626 [1]:
> "assert(ex_map->jvms()->same_calls_as(_exceptions->jvms())) failed: all
> collected exceptions must come from the same place".
>
> 8014447 [2] introduced new code shape for virtual intrinsifiable methods
> (Object::hashCode & Object::clone): "invokevirtual Object.clone()" can
> be represented as a PredictedCallGenerator with LibraryIntrinsic on fast
> path and VirtualCallGenerator on slow path.
>
> The problem arises for Object::clone, because for OOM case intrinsified
> version requires reexecution (reexecute=true), but slow path (virtual
> dispatch) doesn't (reexecute=false). Further attempt to finish the
> diamond and merge 2 exception states fires the assertion.
>
> So, I have 2 questions:
>    (1) I don't see any way to merge reexecute=true & reexecute=false
> states, so both branches should have the same reexecute status. Am I
> missing something?
>
>    (2) Does PredictedCallGenerator actually support such shape
> (intrinsic on fast path)? There are 2 call generators:
> PredictedIntrinsicGenerator & PredictedCallGenerator. What's the
> difference?
>
> I see there's a way to customize predicate in
> LibraryCallKit::try_to_predicate() for PredictedIntrinsicGenerator, but
> is it the only reason why PredictedIntrinsicGenerator was introduced?
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8033626
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8014447
>      "Object.hashCode intrinsic breaks inline caches"

From vladimir.kozlov at oracle.com  Wed May 28 22:46:25 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 28 May 2014 15:46:25 -0700
Subject: RFR(M): 8026796: Make replace_in_map() on parent maps generic
In-Reply-To: <49AC9C55-3889-4C74-92B4-8602EC133557@oracle.com>
References: <9F9E2688-4970-4282-A400-F44DB266B149@oracle.com>
	<8E791232-A0F6-4DC2-B40A-2C28D0E1159A@oracle.com>
	<537A95D6.9020603@oracle.com>
	<49AC9C55-3889-4C74-92B4-8602EC133557@oracle.com>
Message-ID: <53866741.9010102@oracle.com>

May be you should move ReplacedNodes into new files, callnode.* files 
are big already.

When you path ReplacedNodes as parameter can you use & reference instead 
of copy constructor?:

+   void transfer_from(ReplacedNodes other, uint idx);
+   void merge_with(ReplacedNodes other);


The last change in compile.cpp seems unrelated:

+     if (AlwaysIncrementalInline) {
+       inline_incrementally(igvn);
+     }

Thanks,
Vladimir

On 5/23/14 7:48 AM, Roland Westrelin wrote:
> Hi Vladimir,
>
> Here is a new webrev that implements your suggestions:
>
> http://cr.openjdk.java.net/~roland/8026796/webrev.01/
>
> Some comments below:
>
>> Why previous code 8024069 does not work?
>>
>> 'before', 'after' may not good names. You call new nodes 'improved' in the comment you should use it.
>>
>> You meaningful names (not o,n) in record(Node* o, Node* n).
>>
>> It would be nice to use getter/setter functions:
>>
>> ReplacedNodes r = kit.map()->_replaced_nodes;
>> kit.map()->_replaced_nodes = r;
>>
>> Do you have cases when ReplacedNodes could be repopulated? So that we reset length GrowableArray::clear() instead of trashing pointer:
>>
>> +void ReplacedNodes::reset() {
>> +  _replaced_nodes = NULL;
>> +}
>
> I don?t think so but it can?t hurt so I?ve made that change.
>
>> I don't see cleanup of ReplacedNodes in Node::destruct() and other places where we clean up expensive nodes, for example.
>
> I added the cleanup to Node::destruct(). Compile::remove_useless_nodes() does the cleanup as well. I don?t understand why it would be needed elsewhere.
>
>>
>> Is the code in Parse::create_entry_map() correct? First, you destroy ReplacedNodes:
>>
>>   _caller->map()->delete_replaced_nodes();
>>
>> then you used it to initialize new map:
>>
>>   SafePointNode* inmap = _caller->map();
>>   map()->transfer_replaced_nodes_from(inmap, _new_idx);
>
>      GraphKit kit(_caller);
>      kit.null_check_receiver_before_call(method());
>
> between the call to _caller->map()->delete_replaced_nodes() and the map()->transfer_replaced_nodes_from(inmap, _new_idx).
>
> calls replace_in_map() with the caller?s map. map()->transfer_replaced_nodes_from(inmap, _new_idx) is so that we don?t lose track of it.
>
> Roland.
>
>>
>>
>> Thanks,
>> Vladimir
>>
>> On 5/19/14 4:37 AM, Roland Westrelin wrote:
>>> I forgot the webrev:
>>>
>>> http://cr.openjdk.java.net/~roland/8026796/webrev.00/
>>>
>>> Roland.
>>>
>>> On May 19, 2014, at 1:01 PM, Roland Westrelin <roland.westrelin at oracle.com> wrote:
>>>
>>>> This change reverts:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8024069
>>>>
>>>> and propagates replacements in replace_in_map() to callers in a generic way. Every time replace_in_map() is called, the pair of nodes passed to replace_in_map is pushed on a list that the current map carries. When control flow paths merge, the lists for each of the control flow path?s maps are also merged. When parsing exits a method to return to a caller, the replaced nodes on the exit path are used to update the caller's map. This change also propagates replaced nodes after late inlining.
>>>>
>>>> Roland.
>>>
>

From john.r.rose at oracle.com  Wed May 28 23:42:41 2014
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 28 May 2014 16:42:41 -0700
Subject: [8u20,
	9] RFR(S): 8011646	: SEGV in compiled code with loop predication
In-Reply-To: <53865ADA.7070208@oracle.com>
References: <5386361E.8020903@oracle.com>	<9401C93A-028E-40D5-BBBA-85B2B61CD73A@oracle.com>
	<538657D1.3020706@oracle.com> <53865ADA.7070208@oracle.com>
Message-ID: <31BFB28F-6A42-4FAC-B721-F4D0484FF474@oracle.com>

On May 28, 2014, at 2:53 PM, Albert <albert.noll at oracle.com> wrote:

>> It is only 'Node *' to 'Node* ' change. 'udiffs' show that cleanly.
>> 
> Yes, I just put the '*' uniformly to the left side.

(Which is fine BTW, since the majority usage is "T* x" not "T *x"; https://wiki.openjdk.java.net/display/HotSpot/StyleGuide points out we do such adjustments.)

Are there any other places where C2 uses normal IR to access the mark word of an object, and if so, is a similar bug fix needed there?  If so, the tricky logic for building the free-standing LoadXNode needs to be factored into a subroutine.

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140528/e0913ce2/attachment.html>

From vladimir.kozlov at oracle.com  Thu May 29 01:29:36 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 28 May 2014 18:29:36 -0700
Subject: [8u20,
	9] RFR(S): 8011646	: SEGV in compiled code with loop predication
In-Reply-To: <31BFB28F-6A42-4FAC-B721-F4D0484FF474@oracle.com>
References: <5386361E.8020903@oracle.com>	<9401C93A-028E-40D5-BBBA-85B2B61CD73A@oracle.com>	<538657D1.3020706@oracle.com>
	<53865ADA.7070208@oracle.com>
	<31BFB28F-6A42-4FAC-B721-F4D0484FF474@oracle.com>
Message-ID: <53868D80.5030303@oracle.com>

On 5/28/14 4:42 PM, John Rose wrote:
> On May 28, 2014, at 2:53 PM, Albert <albert.noll at oracle.com
> <mailto:albert.noll at oracle.com>> wrote:
>
>>> It is only 'Node *' to 'Node* ' change. 'udiffs' show that cleanly.
>>>
>> Yes, I just put the '*' uniformly to the left side.
>
> (Which is fine BTW, since the majority usage is "T* x" not "T *x";
> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide points out we
> do such adjustments.)
>
> Are there any other places where C2 uses normal IR to access the mark
> word of an object, and if so, is a similar bug fix needed there?  If so,
> the tricky logic for building the free-standing LoadXNode needs to be
> factored into a subroutine.

There are several places in macro.cpp in expand_lock_node() and 
expand_unlock_node() which takes control. Note, LockNode is call node 
and always has control. I thought about this part yesterday but said 
nothing because we did not have any problems with that code before. And 
we need more testing if we remove these control edges.

Originally these loads were RAW memory operations and required to have 
control to prevent skipping safepoints.

Vladimir

>
> ? John

From vladimir.x.ivanov at oracle.com  Thu May 29 09:14:54 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 29 May 2014 13:14:54 +0400
Subject: Regarding 8033626: C2: Merging exception state: reexecute=true
	vs reexecute=false
In-Reply-To: <5386609F.7030206@oracle.com>
References: <538610B9.6060008@oracle.com> <5386609F.7030206@oracle.com>
Message-ID: <5386FA8E.6010901@oracle.com>

The problem is with exception state of two branches [1].
Exception on fast path comes from GraphKit::new_instance during 
intrinsic construction in LibraryCallKit::inline_native_clone. It is 
executed under should_reexecute=true. PreserveReexecuteState doesn't 
touch exception state, so kit.add_exception_states_from(new_jvms) (@ 
callGenerator.cpp:703) tries to accumulate incompatible exceptions from 
fast & slow paths.

Best regards,
Vladimir Ivanov

[1] FAST PATH (intrinsic):

JVMS depth=1 loc=5 stk=9 arg=10 mon=14 scalar=14 end=14 mondepth=0 sp=1 
bci=12 reexecute=false method=virtual jobject

Exception state:

JVMS depth=1 loc=5 stk=9 arg=9 mon=14 scalar=14 end=14 mondepth=0 sp=0 
bci=12 reexecute=true method=virtual jobject

SLOW PATH

JVMS depth=1 loc=5 stk=9 arg=10 mon=14 scalar=14 end=14 mondepth=0 sp=1 
bci=12 reexecute=false method=virtual jobject

Exception state:

JVMS depth=1 loc=5 stk=9 arg=9 mon=14 scalar=14 end=14 mondepth=0 sp=0 
bci=12 reexecute=false method=virtual jobject


On 5/29/14 2:18 AM, Vladimir Kozlov wrote:
> PredictedIntrinsicGenerator was added to have a general predicate. For
> example, AES crypto predicate checks klass of an object pointed by a
> field. PredictedCallGenerator checks klass of method's holder only.
>
> Both cases would have the same problem with reexecute. Using
> PredictedIntrinsicGenerator will not help you.
>
> But you should not have this problem at the merge point, because
> reexecute should be reset back after intrinsic is generated:
>
>    { PreserveReexecuteState preexecs(this);
>      jvms()->set_should_reexecute(true);
>
> It is strange that it is still true after PreserveReexecuteState
> destructor.
>
> Vladimir K
>
> On 5/28/14 9:37 AM, Vladimir Ivanov wrote:
>> Hi,
>>
>> I'm looking at 8033626 [1]:
>> "assert(ex_map->jvms()->same_calls_as(_exceptions->jvms())) failed: all
>> collected exceptions must come from the same place".
>>
>> 8014447 [2] introduced new code shape for virtual intrinsifiable methods
>> (Object::hashCode & Object::clone): "invokevirtual Object.clone()" can
>> be represented as a PredictedCallGenerator with LibraryIntrinsic on fast
>> path and VirtualCallGenerator on slow path.
>>
>> The problem arises for Object::clone, because for OOM case intrinsified
>> version requires reexecution (reexecute=true), but slow path (virtual
>> dispatch) doesn't (reexecute=false). Further attempt to finish the
>> diamond and merge 2 exception states fires the assertion.
>>
>> So, I have 2 questions:
>>    (1) I don't see any way to merge reexecute=true & reexecute=false
>> states, so both branches should have the same reexecute status. Am I
>> missing something?
>>
>>    (2) Does PredictedCallGenerator actually support such shape
>> (intrinsic on fast path)? There are 2 call generators:
>> PredictedIntrinsicGenerator & PredictedCallGenerator. What's the
>> difference?
>>
>> I see there's a way to customize predicate in
>> LibraryCallKit::try_to_predicate() for PredictedIntrinsicGenerator, but
>> is it the only reason why PredictedIntrinsicGenerator was introduced?
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8033626
>>
>> [2] https://bugs.openjdk.java.net/browse/JDK-8014447
>>      "Object.hashCode intrinsic breaks inline caches"

From vladimir.x.ivanov at oracle.com  Thu May 29 09:32:55 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 29 May 2014 13:32:55 +0400
Subject: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling
	with DirectMethodHandle
In-Reply-To: <5385760E.3040109@oracle.com>
References: <5383951A.1070104@oracle.com> <5385760E.3040109@oracle.com>
Message-ID: <5386FEC7.7080501@oracle.com>

John, Serguei, thanks for review.

Best regards,
Vladimir Ivanov

On 5/28/14 9:37 AM, serguei.spitsyn at oracle.com wrote:
> Vladimir,
>
> It looks good.
>
> Thanks,
> Serguei
>
> On 5/26/14 12:25 PM, Vladimir Ivanov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8034935
>> http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00
>>
>> Citing John's explanation of motivation for this change (from the bug):
>> "There is a coupling from bytecodes that call
>> MethodHandle.linkToStatic (and similar "linker methods") and the
>> PopFrame feature. The linker methods accept an extra "appendix
>> argument" of type MemberName which is popped from the list before
>> vectoring to the desired method (it supplies the name of that method).
>>
>> In order to re-execute the call, the MemberName must be recovered
>> somehow. Currently, the JVM assumes that the interpreter frame's local
>> #0 will contain a DirectMethodHandle which holds the desired
>> MemberName. The JVM should also accept the MemberName itself, and
>> eventually stop looking for the DirectMethodHandle.
>>
>> This will simplify the handshake between JVM and JSR 292
>> implementation bytecodes. The DMH is difficult to recover at the point
>> of call to linkToStatic, although the MemberName is guaranteed live at
>> that point.
>>
>> Also, making this change (perhaps in two steps) will allow the JVM to
>> stop coupling to SystemDictionary::DirectMethodHandle_klass. Such
>> couplings should be minimized."
>>
>> Testing: JPRT, jtreg (java/lang/invoke), vm.mlvm.testlist
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>

From vitalyd at gmail.com  Thu May 29 16:01:16 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 29 May 2014 12:01:16 -0400
Subject: CodeHeap::expand_by malloc failed
Message-ID: <CAHjP37Ea3=tpCUSMnbx4pLrXbWGjXTb19BSD23uJUCgFSwC8ow@mail.gmail.com>

Hi guys,

Need a bit of help explaining a hotspot malloc failure crash on 7u51.  I'm
going to paste the relevant snippets from the hs_err log.

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 65536 bytes for
committing reserved memory.
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (os_linux.cpp:2726), pid=10643, tid=47319048501520
#
# JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build
1.7.0_51-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode
linux-amd64 compressed oops)


---------------  T H R E A D  ---------------

Current thread (0x0000000000716800):  JavaThread "C2 CompilerThread0"
daemon [_thread_in_vm, id=10689,
stack(0x00002b095303b000,0x00002b095313c000)]

Stack: [0x00002b095303b000,0x00002b095313c000],  sp=0x00002b0953138d20,
 free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0x992f4a]  VMError::report_and_die()+0x2ea
V  [libjvm.so+0x4931ab]  report_vm_out_of_memory(char const*, int, unsigned
long, char const*)+0x9b
V  [libjvm.so+0x81338e]  os::Linux::commit_memory_impl(char*, unsigned
long, bool)+0xfe
V  [libjvm.so+0x81383f]  os::Linux::commit_memory_impl(char*, unsigned
long, unsigned long, bool)+0x4f
V  [libjvm.so+0x813a2c]  os::pd_commit_memory(char*, unsigned long,
unsigned long, bool)+0xc
V  [libjvm.so+0x80daea]  os::commit_memory(char*, unsigned long, unsigned
long, bool)+0x2a
V  [libjvm.so+0x98e849]  VirtualSpace::expand_by(unsigned long, bool)+0x1c9
V  [libjvm.so+0x58a62c]  CodeHeap::expand_by(unsigned long)+0x8c
V  [libjvm.so+0x42111d]  CodeCache::allocate(int)+0x4d
V  [libjvm.so+0x7e1a39]  nmethod::new_nmethod(methodHandle, int, int,
CodeOffsets*, int, DebugInformationRecorder*, Dependencies*, CodeBuffer*,
int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*,
AbstractCompiler*, int)+0x179
V  [libjvm.so+0x3cfc54]  ciEnv::register_method(ciMethod*, int,
CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
ImplicitExceptionTable*, AbstractCompiler*, int, bool, bool)+0x364
V  [libjvm.so+0x4458fb]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*,
int, bool, bool)+0x11cb
V  [libjvm.so+0x3afa76]  C2Compiler::compile_method(ciEnv*, ciMethod*,
int)+0x176
V  [libjvm.so+0x44ba9e]
 CompileBroker::invoke_compiler_on_method(CompileTask*)+0x33e
V  [libjvm.so+0x44c87d]  CompileBroker::compiler_thread_loop()+0x43d
V  [libjvm.so+0x94d5ff]  JavaThread::thread_main_inner()+0xdf
V  [libjvm.so+0x94d705]  JavaThread::run()+0xf5
V  [libjvm.so+0x815538]  java_start(Thread*)+0x108

Code Cache  [0x00002b091755c000, 0x00002b091869c000, 0x00002b091a55c000)
 total_blobs=7033 nmethods=6349 adapters=634 free_code_cache=31715Kb
largest_free_block=32247296

Memory mappings around the code cache virtual space (bolded line is the
code cache segment, I believe, based on the Code Cache output above):

*2b091755c000-2b091869c000 rwxp 00000000 00:00 0*
2b09186ac000-2b091d66f000 rw-p 00000000 00:00 0
2b091d66f000-2b091d670000 ---p 00000000 00:00 0
2b091d670000-2b091d770000 rwxp 00000000 00:00 0
2b091d770000-2b091d771000 ---p 00000000 00:00 0
2b091d771000-2b091d871000 rwxp 00000000 00:00 0
2b091d871000-2b091d872000 ---p 00000000 00:00 0
2b091d872000-2b091d972000 rwxp 00000000 00:00 0

/proc/meminfo:
MemTotal:       49521668 kB
MemFree:         5596796 kB
Buffers:          294684 kB
Cached:         34205856 kB
SwapCached:            0 kB
Active:         12745128 kB
Inactive:       28516788 kB
Active(anon):    9280636 kB
Inactive(anon):  3090264 kB
Active(file):    3464492 kB
Inactive(file): 25426524 kB
Unevictable:       14420 kB
Mlocked:           14420 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:             20392 kB
Writeback:             0 kB
AnonPages:       6776540 kB
Mapped:          6292204 kB
Shmem:           5604620 kB
Slab:            1828656 kB
SReclaimable:    1567928 kB
SUnreclaim:       260728 kB
KernelStack:        4648 kB
PageTables:        58800 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    47045584 kB
Committed_AS:   46046480 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      460188 kB
VmallocChunk:   34333703480 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        8192 kB
DirectMap2M:     2080768 kB
DirectMap1G:    48234496 kB

Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)

* overcommit is turned off

So the code heap was attempting to expand by 65kb at a fixed address.
 There appears to be a 65kb mapping available between the end of the
current code heap mapping (2b091755c000-2b091869c000) and the next one
(2b09186ac000-2b091d66f000).  There's about 30mb of free space left
(reserved, but uncommitted I take it) in the virtual space, so it's a bit
puzzling given there's ample physical mem available.  Only thing I can
think of is expansion fails because it cannot get contiguous space, but
then I can't reconcile that with the mem mapping above.

Does anyone have any ideas?

Let me know if you need additional info from the hs_err file.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140529/37fdf290/attachment-0001.html>

From biboudis at gmail.com  Thu May 29 17:55:01 2014
From: biboudis at gmail.com (Aggelos Biboudis)
Date: Thu, 29 May 2014 20:55:01 +0300
Subject: Request for tracking down C1 optimizations: handwritten cartesian
	product similar to flatmap/map performance!
Message-ID: <CAHLSyCko2tnaRhL8pEp1Oiwy2KM+AnhC1R7HSUAJc1hueSN6LQ@mail.gmail.com>

Hello all,

I would like to ask you something regarding C1 compilation (VM options:
-Xms769m -Xmx769m -XX:-TieredCompilation) of a Cartesian product stream
operation with the new stream API.
I have two versions of this computation, one handwritten and one with
flatmap/map. It is remarkable that these two have similar performance so I
would like to trace-back the JIT compilation decisions (apart from
inlining), and more specifically if escape analysis has any effect.

...
>
> valuesHi = IntStream.range(0, 10000).mapToLong(i -> i).toArray();
> valuesLo = IntStream.range(0, 1000).mapToLong(i -> i).toArray();
>
> @GenerateMicroBenchmark // -> 4.984 ms / op on avg
> public long cartSeq() {
>    long cart
>          = LongStream.of(valuesHi)
>             .flatMap(d -> LongStream.of(valuesLo).map(dP -> dP * d))
>             .sum();
>    return cart;
> }
>
> @GenerateMicroBenchmark // -> 4.258 ms / op on avg
> public long cartBaseline() {
>     long cart = 0;
>     for (int d = 0 ; d < valuesHi.length ; d++) {
>         for (int dp = 0 ; dp < valuesLo.length ; dp++){
>         cart += valuesHi[d] * valuesLo[dp];
>         }
>     }
>     return cart;
> }
>

I've tested the code above with -XX:-DoEscapeAnalysis and I've got the same
execution times, however I would like to confirm what happens.
Regarding inlining, only by noticing the result of PrintInlining we
conclude that cartSeq inlines all the nested forEachRemaining operations
(of of, flatmap, map), but is that the only optimization?

Thank you in advance!

Cheers,
Aggelos Biboudis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140529/0d553d1b/attachment.html>

From aph at redhat.com  Thu May 29 18:03:25 2014
From: aph at redhat.com (Andrew Haley)
Date: Thu, 29 May 2014 19:03:25 +0100
Subject: Request for tracking down C1 optimizations: handwritten cartesian
	product similar to flatmap/map performance!
In-Reply-To: <CAHLSyCko2tnaRhL8pEp1Oiwy2KM+AnhC1R7HSUAJc1hueSN6LQ@mail.gmail.com>
References: <CAHLSyCko2tnaRhL8pEp1Oiwy2KM+AnhC1R7HSUAJc1hueSN6LQ@mail.gmail.com>
Message-ID: <5387766D.3020207@redhat.com>

Hi,

On 05/29/2014 06:55 PM, Aggelos Biboudis wrote:

> I would like to ask you something regarding C1 compilation (VM options:
> -Xms769m -Xmx769m -XX:-TieredCompilation)

That's C2 compilation.

> of a Cartesian product stream
> operation with the new stream API.
> I have two versions of this computation, one handwritten and one with
> flatmap/map. It is remarkable that these two have similar performance so I
> would like to trace-back the JIT compilation decisions (apart from
> inlining), and more specifically if escape analysis has any effect.

Are you quite sure your numbers aren't dominated by cache misses?  Your
data is about 40 Megabytes and it's being accessed sequentially.

> I've tested the code above with -XX:-DoEscapeAnalysis and I've got the same
> execution times, however I would like to confirm what happens.
> Regarding inlining, only by noticing the result of PrintInlining we
> conclude that cartSeq inlines all the nested forEachRemaining operations
> (of of, flatmap, map), but is that the only optimization?

Not if this really is C2, no.  There are many optimization passes,
and several will be effective for this code.

Andrew.


From biboudis at gmail.com  Thu May 29 18:39:36 2014
From: biboudis at gmail.com (Aggelos Biboudis)
Date: Thu, 29 May 2014 21:39:36 +0300
Subject: Request for tracking down C1 optimizations: handwritten cartesian
	product similar to flatmap/map performance!
In-Reply-To: <5387766D.3020207@redhat.com>
References: <CAHLSyCko2tnaRhL8pEp1Oiwy2KM+AnhC1R7HSUAJc1hueSN6LQ@mail.gmail.com>
	<5387766D.3020207@redhat.com>
Message-ID: <CAHLSyC=7e=83QWO3id=-ipQHcNvtqEKnJAKFrNnV5-4e-89HRw@mail.gmail.com>

Of course, C2, my bad.

Regarding cache misses, I have to examine if loop interchange happens and
in general what x86 code is emitted but thanks for pointing that out.

Aggelos



On Thu, May 29, 2014 at 9:03 PM, Andrew Haley <aph at redhat.com> wrote:

> Hi,
>
> On 05/29/2014 06:55 PM, Aggelos Biboudis wrote:
>
> > I would like to ask you something regarding C1 compilation (VM options:
> > -Xms769m -Xmx769m -XX:-TieredCompilation)
>
> That's C2 compilation.
>
> > of a Cartesian product stream
> > operation with the new stream API.
> > I have two versions of this computation, one handwritten and one with
> > flatmap/map. It is remarkable that these two have similar performance so
> I
> > would like to trace-back the JIT compilation decisions (apart from
> > inlining), and more specifically if escape analysis has any effect.
>
> Are you quite sure your numbers aren't dominated by cache misses?  Your
> data is about 40 Megabytes and it's being accessed sequentially.
>
> > I've tested the code above with -XX:-DoEscapeAnalysis and I've got the
> same
> > execution times, however I would like to confirm what happens.
> > Regarding inlining, only by noticing the result of PrintInlining we
> > conclude that cartSeq inlines all the nested forEachRemaining operations
> > (of of, flatmap, map), but is that the only optimization?
>
> Not if this really is C2, no.  There are many optimization passes,
> and several will be effective for this code.
>
> Andrew.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140529/29b0b421/attachment.html>

From albert.noll at oracle.com  Thu May 29 19:17:50 2014
From: albert.noll at oracle.com (Albert)
Date: Thu, 29 May 2014 21:17:50 +0200
Subject: [8u20,
	9] RFR(S): 8011646	: SEGV in compiled code with loop predication
In-Reply-To: <53868D80.5030303@oracle.com>
References: <5386361E.8020903@oracle.com>	<9401C93A-028E-40D5-BBBA-85B2B61CD73A@oracle.com>	<538657D1.3020706@oracle.com>	<53865ADA.7070208@oracle.com>	<31BFB28F-6A42-4FAC-B721-F4D0484FF474@oracle.com>
	<53868D80.5030303@oracle.com>
Message-ID: <538787DE.2090901@oracle.com>

John, Vladimir, thanks for your comments.

How shall we proceed with this bug? Is it OK to push this change?
Shall I file an RFE that suggests to further investigate possible issues
at the places that Vladimir mentioned?

Best,
Albert


On 05/29/2014 03:29 AM, Vladimir Kozlov wrote:
> On 5/28/14 4:42 PM, John Rose wrote:
>> On May 28, 2014, at 2:53 PM, Albert <albert.noll at oracle.com
>> <mailto:albert.noll at oracle.com>> wrote:
>>
>>>> It is only 'Node *' to 'Node* ' change. 'udiffs' show that cleanly.
>>>>
>>> Yes, I just put the '*' uniformly to the left side.
>>
>> (Which is fine BTW, since the majority usage is "T* x" not "T *x";
>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide points out we
>> do such adjustments.)
>>
>> Are there any other places where C2 uses normal IR to access the mark
>> word of an object, and if so, is a similar bug fix needed there?  If so,
>> the tricky logic for building the free-standing LoadXNode needs to be
>> factored into a subroutine.
>
> There are several places in macro.cpp in expand_lock_node() and 
> expand_unlock_node() which takes control. Note, LockNode is call node 
> and always has control. I thought about this part yesterday but said 
> nothing because we did not have any problems with that code before. 
> And we need more testing if we remove these control edges.
>
> Originally these loads were RAW memory operations and required to have 
> control to prevent skipping safepoints.
>
> Vladimir
>
>>
>> ? John


From david.r.chase at oracle.com  Thu May 29 20:04:20 2014
From: david.r.chase at oracle.com (David Chase)
Date: Thu, 29 May 2014 16:04:20 -0400
Subject: RFR (XS): 8043207: Add const to Address argument for
	Assembler::swap
In-Reply-To: <53860C00.2010604@oracle.com>
References: <53860C00.2010604@oracle.com>
Message-ID: <0664E742-3FD6-4ABE-B25A-4379E7556FD0@oracle.com>

Any testing?  (and except for that issue, I, a non-Reviewer, approve)

On 2014-05-28, at 12:17 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:

> Please review the following fix which changes one of the Assembler::swap methods to take a *const* Address argument instead of a non-const. Some of the usages of the swap method pass a const argument, and when compiling with gcc the const-ness mismatch means the method cannot be resolved which in turn means a compilation error. This is for jdk7u (only) - the relevant code has been rewritten in jdk8+ to no longer have this problem.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8043207
> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8043207/webrev.00/webrev/
> 
> Thanks,
> Mikael
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140529/21cc6ba8/signature.asc>

From mikael.vidstedt at oracle.com  Thu May 29 20:12:03 2014
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Thu, 29 May 2014 13:12:03 -0700
Subject: RFR (XS): 8043207: Add const to Address argument for
	Assembler::swap
In-Reply-To: <0664E742-3FD6-4ABE-B25A-4379E7556FD0@oracle.com>
References: <53860C00.2010604@oracle.com>
	<0664E742-3FD6-4ABE-B25A-4379E7556FD0@oracle.com>
Message-ID: <53879493.9060601@oracle.com>


Since this is a build problem the testing pretty much comes with 
building on the relevant platforms, which all pass with the fix in place.

Cheers,
Mikael

On 2014-05-29 13:04, David Chase wrote:
> Any testing?  (and except for that issue, I, a non-Reviewer, approve)
>
> On 2014-05-28, at 12:17 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
>
>> Please review the following fix which changes one of the Assembler::swap methods to take a *const* Address argument instead of a non-const. Some of the usages of the swap method pass a const argument, and when compiling with gcc the const-ness mismatch means the method cannot be resolved which in turn means a compilation error. This is for jdk7u (only) - the relevant code has been rewritten in jdk8+ to no longer have this problem.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043207
>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8043207/webrev.00/webrev/
>>
>> Thanks,
>> Mikael
>>


From vladimir.kozlov at oracle.com  Thu May 29 21:59:31 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 29 May 2014 14:59:31 -0700
Subject: [8u20,
	9] RFR(S): 8011646	: SEGV in compiled code with loop predication
In-Reply-To: <538787DE.2090901@oracle.com>
References: <5386361E.8020903@oracle.com>	<9401C93A-028E-40D5-BBBA-85B2B61CD73A@oracle.com>	<538657D1.3020706@oracle.com>	<53865ADA.7070208@oracle.com>	<31BFB28F-6A42-4FAC-B721-F4D0484FF474@oracle.com>	<53868D80.5030303@oracle.com>
	<538787DE.2090901@oracle.com>
Message-ID: <5387ADC3.80200@oracle.com>


On 5/29/14 12:17 PM, Albert wrote:
> John, Vladimir, thanks for your comments.
>
> How shall we proceed with this bug? Is it OK to push this change?
> Shall I file an RFE that suggests to further investigate possible issues
> at the places that Vladimir mentioned?

I think we need to do only point fix in inline_native_hashcode() now and 
file RFE to investigate other cases (including Parse::array_load() as 
Roland pointed). May be find general solution when we have dependency on 
several controls. Actually we already have BUG for this:

https://bugs.openjdk.java.net/browse/JDK-6831314

I can assigned it to you, Albert, if you want.

Thanks,
Vladimir

>
> Best,
> Albert
>
>
> On 05/29/2014 03:29 AM, Vladimir Kozlov wrote:
>> On 5/28/14 4:42 PM, John Rose wrote:
>>> On May 28, 2014, at 2:53 PM, Albert <albert.noll at oracle.com
>>> <mailto:albert.noll at oracle.com>> wrote:
>>>
>>>>> It is only 'Node *' to 'Node* ' change. 'udiffs' show that cleanly.
>>>>>
>>>> Yes, I just put the '*' uniformly to the left side.
>>>
>>> (Which is fine BTW, since the majority usage is "T* x" not "T *x";
>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide points out we
>>> do such adjustments.)
>>>
>>> Are there any other places where C2 uses normal IR to access the mark
>>> word of an object, and if so, is a similar bug fix needed there?  If so,
>>> the tricky logic for building the free-standing LoadXNode needs to be
>>> factored into a subroutine.
>>
>> There are several places in macro.cpp in expand_lock_node() and
>> expand_unlock_node() which takes control. Note, LockNode is call node
>> and always has control. I thought about this part yesterday but said
>> nothing because we did not have any problems with that code before.
>> And we need more testing if we remove these control edges.
>>
>> Originally these loads were RAW memory operations and required to have
>> control to prevent skipping safepoints.
>>
>> Vladimir
>>
>>>
>>> ? John
>

From christian.thalinger at oracle.com  Fri May 30 00:31:29 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 29 May 2014 17:31:29 -0700
Subject: RFR(M): 7033917: closed/compiler/6507107/HeapwalkingTest.java
	sometimes works too long
In-Reply-To: <537F5B70.5040508@oracle.com>
References: <537F5B70.5040508@oracle.com>
Message-ID: <67C6F33F-CEB9-4206-BFA8-F4658ACBE31B@oracle.com>

Igor, Christian, could you guys review this change?

On May 23, 2014, at 7:30 AM, Morris Meyer <morris.meyer at oracle.com> wrote:

> Folks,
> 
> During the nightly testing we have a class of bugs that crop up with compiler flags that change the performance dynamic of the test, such as -Xcomp and -XX:+DeoptimizeALot.
> 
> Instead of tweaking the test parameters, I have created an Estimator class that takes a work List - and creates an Iterator that is looking at the expiration clock for the test.  Instead of the test failing out for taking too much time for an arbitrary number of iterations, the iterator ends, and Estimator will produce a timeout factor suitable for the -Dtest.timeout.factor flag.
> 
> I've added an EstimatorTest to testlibrary_tests that tests the Estimator with three scenarios, too much time, not enough time and just enough time.
> 
> This test has also been through JPRT.   The changes HeapwalkingTest will be sent out for review to the closed list.
> 
> Thanks much,
> 
>        --morris meyer
> 
> 
> WEBREV - http://cr.openjdk.java.net/~morris/JDK-7033917-hotspot.01
> JBS - https://bugs.openjdk.java.net/browse/JDK-7033917
> 
> 


From christian.thalinger at oracle.com  Fri May 30 00:35:28 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 29 May 2014 17:35:28 -0700
Subject: CodeHeap::expand_by malloc failed
In-Reply-To: <CAHjP37Ea3=tpCUSMnbx4pLrXbWGjXTb19BSD23uJUCgFSwC8ow@mail.gmail.com>
References: <CAHjP37Ea3=tpCUSMnbx4pLrXbWGjXTb19BSD23uJUCgFSwC8ow@mail.gmail.com>
Message-ID: <E2B85BDE-7F4B-4025-B29E-AFD1AEBCE17D@oracle.com>

Although it?s the code cache I assume runtime folk would know more about this.  Maybe send to hotspot-dev.

On May 29, 2014, at 9:01 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Hi guys,
> 
> Need a bit of help explaining a hotspot malloc failure crash on 7u51.  I'm going to paste the relevant snippets from the hs_err log.
> 
> #
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (malloc) failed to allocate 65536 bytes for committing reserved memory.
> # Possible reasons:
> #   The system is out of physical RAM or swap space
> #   In 32 bit mode, the process size limit was hit
> # Possible solutions:
> #   Reduce memory load on the system
> #   Increase physical memory or swap space
> #   Check if swap backing store is full
> #   Use 64 bit Java on a 64 bit OS
> #   Decrease Java heap size (-Xmx/-Xms)
> #   Decrease number of Java threads
> #   Decrease Java thread stack sizes (-Xss)
> #   Set larger code cache with -XX:ReservedCodeCacheSize=
> # This output file may be truncated or incomplete.
> #
> #  Out of Memory Error (os_linux.cpp:2726), pid=10643, tid=47319048501520
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build 1.7.0_51-b13)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode linux-amd64 compressed oops)
> 
> 
> ---------------  T H R E A D  ---------------
> 
> Current thread (0x0000000000716800):  JavaThread "C2 CompilerThread0" daemon [_thread_in_vm, id=10689, stack(0x00002b095303b000,0x00002b095313c000)]
> 
> Stack: [0x00002b095303b000,0x00002b095313c000],  sp=0x00002b0953138d20,  free space=1015k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x992f4a]  VMError::report_and_die()+0x2ea
> V  [libjvm.so+0x4931ab]  report_vm_out_of_memory(char const*, int, unsigned long, char const*)+0x9b
> V  [libjvm.so+0x81338e]  os::Linux::commit_memory_impl(char*, unsigned long, bool)+0xfe
> V  [libjvm.so+0x81383f]  os::Linux::commit_memory_impl(char*, unsigned long, unsigned long, bool)+0x4f
> V  [libjvm.so+0x813a2c]  os::pd_commit_memory(char*, unsigned long, unsigned long, bool)+0xc
> V  [libjvm.so+0x80daea]  os::commit_memory(char*, unsigned long, unsigned long, bool)+0x2a
> V  [libjvm.so+0x98e849]  VirtualSpace::expand_by(unsigned long, bool)+0x1c9
> V  [libjvm.so+0x58a62c]  CodeHeap::expand_by(unsigned long)+0x8c
> V  [libjvm.so+0x42111d]  CodeCache::allocate(int)+0x4d
> V  [libjvm.so+0x7e1a39]  nmethod::new_nmethod(methodHandle, int, int, CodeOffsets*, int, DebugInformationRecorder*, Dependencies*, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, int)+0x179
> V  [libjvm.so+0x3cfc54]  ciEnv::register_method(ciMethod*, int, CodeOffsets*, int, CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*, int, bool, bool)+0x364
> V  [libjvm.so+0x4458fb]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool)+0x11cb
> V  [libjvm.so+0x3afa76]  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x176
> V  [libjvm.so+0x44ba9e]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x33e
> V  [libjvm.so+0x44c87d]  CompileBroker::compiler_thread_loop()+0x43d
> V  [libjvm.so+0x94d5ff]  JavaThread::thread_main_inner()+0xdf
> V  [libjvm.so+0x94d705]  JavaThread::run()+0xf5
> V  [libjvm.so+0x815538]  java_start(Thread*)+0x108
> 
> Code Cache  [0x00002b091755c000, 0x00002b091869c000, 0x00002b091a55c000)
>  total_blobs=7033 nmethods=6349 adapters=634 free_code_cache=31715Kb largest_free_block=32247296
> 
> Memory mappings around the code cache virtual space (bolded line is the code cache segment, I believe, based on the Code Cache output above):
> 
> 2b091755c000-2b091869c000 rwxp 00000000 00:00 0
> 2b09186ac000-2b091d66f000 rw-p 00000000 00:00 0
> 2b091d66f000-2b091d670000 ---p 00000000 00:00 0
> 2b091d670000-2b091d770000 rwxp 00000000 00:00 0
> 2b091d770000-2b091d771000 ---p 00000000 00:00 0
> 2b091d771000-2b091d871000 rwxp 00000000 00:00 0
> 2b091d871000-2b091d872000 ---p 00000000 00:00 0
> 2b091d872000-2b091d972000 rwxp 00000000 00:00 0
> 
> /proc/meminfo:
> MemTotal:       49521668 kB
> MemFree:         5596796 kB
> Buffers:          294684 kB
> Cached:         34205856 kB
> SwapCached:            0 kB
> Active:         12745128 kB
> Inactive:       28516788 kB
> Active(anon):    9280636 kB
> Inactive(anon):  3090264 kB
> Active(file):    3464492 kB
> Inactive(file): 25426524 kB
> Unevictable:       14420 kB
> Mlocked:           14420 kB
> SwapTotal:             0 kB
> SwapFree:              0 kB
> Dirty:             20392 kB
> Writeback:             0 kB
> AnonPages:       6776540 kB
> Mapped:          6292204 kB
> Shmem:           5604620 kB
> Slab:            1828656 kB
> SReclaimable:    1567928 kB
> SUnreclaim:       260728 kB
> KernelStack:        4648 kB
> PageTables:        58800 kB
> NFS_Unstable:          0 kB
> Bounce:                0 kB
> WritebackTmp:          0 kB
> CommitLimit:    47045584 kB
> Committed_AS:   46046480 kB
> VmallocTotal:   34359738367 kB
> VmallocUsed:      460188 kB
> VmallocChunk:   34333703480 kB
> HugePages_Total:       0
> HugePages_Free:        0
> HugePages_Rsvd:        0
> HugePages_Surp:        0
> Hugepagesize:       2048 kB
> DirectMap4k:        8192 kB
> DirectMap2M:     2080768 kB
> DirectMap1G:    48234496 kB
> 
> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
> 
> * overcommit is turned off
> 
> So the code heap was attempting to expand by 65kb at a fixed address.  There appears to be a 65kb mapping available between the end of the current code heap mapping (2b091755c000-2b091869c000) and the next one (2b09186ac000-2b091d66f000).  There's about 30mb of free space left (reserved, but uncommitted I take it) in the virtual space, so it's a bit puzzling given there's ample physical mem available.  Only thing I can think of is expansion fails because it cannot get contiguous space, but then I can't reconcile that with the mem mapping above. 
> 
> Does anyone have any ideas?
> 
> Let me know if you need additional info from the hs_err file.
> 
> Thanks
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140529/525c641e/attachment.html>

From vladimir.kozlov at oracle.com  Fri May 30 00:48:05 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 29 May 2014 17:48:05 -0700
Subject: CodeHeap::expand_by malloc failed
In-Reply-To: <E2B85BDE-7F4B-4025-B29E-AFD1AEBCE17D@oracle.com>
References: <CAHjP37Ea3=tpCUSMnbx4pLrXbWGjXTb19BSD23uJUCgFSwC8ow@mail.gmail.com>
	<E2B85BDE-7F4B-4025-B29E-AFD1AEBCE17D@oracle.com>
Message-ID: <5387D545.9080404@oracle.com>

Could be because there is no swap on this machine:

Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)

Vladimir

On 5/29/14 5:35 PM, Christian Thalinger wrote:
> Although it?s the code cache I assume runtime folk would know more about
> this.  Maybe send to hotspot-dev.
>
> On May 29, 2014, at 9:01 AM, Vitaly Davidovich <vitalyd at gmail.com
> <mailto:vitalyd at gmail.com>> wrote:
>
>> Hi guys,
>>
>> Need a bit of help explaining a hotspot malloc failure crash on 7u51.
>>  I'm going to paste the relevant snippets from the hs_err log.
>>
>> #
>> # There is insufficient memory for the Java Runtime Environment to
>> continue.
>> # Native memory allocation (malloc) failed to allocate 65536 bytes for
>> committing reserved memory.
>> # Possible reasons:
>> #   The system is out of physical RAM or swap space
>> #   In 32 bit mode, the process size limit was hit
>> # Possible solutions:
>> #   Reduce memory load on the system
>> #   Increase physical memory or swap space
>> #   Check if swap backing store is full
>> #   Use 64 bit Java on a 64 bit OS
>> #   Decrease Java heap size (-Xmx/-Xms)
>> #   Decrease number of Java threads
>> #   Decrease Java thread stack sizes (-Xss)
>> #   Set larger code cache with -XX:ReservedCodeCacheSize=
>> # This output file may be truncated or incomplete.
>> #
>> #  Out of Memory Error (os_linux.cpp:2726), pid=10643, tid=47319048501520
>> #
>> # JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build
>> 1.7.0_51-b13)
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode
>> linux-amd64 compressed oops)
>>
>>
>> ---------------  T H R E A D  ---------------
>>
>> Current thread (0x0000000000716800):  JavaThread "C2 CompilerThread0"
>> daemon [_thread_in_vm, id=10689,
>> stack(0x00002b095303b000,0x00002b095313c000)]
>>
>> Stack: [0x00002b095303b000,0x00002b095313c000],
>>  sp=0x00002b0953138d20,  free space=1015k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>> C=native code)
>> V  [libjvm.so+0x992f4a]  VMError::report_and_die()+0x2ea
>> V  [libjvm.so+0x4931ab]  report_vm_out_of_memory(char const*, int,
>> unsigned long, char const*)+0x9b
>> V  [libjvm.so+0x81338e]  os::Linux::commit_memory_impl(char*, unsigned
>> long, bool)+0xfe
>> V  [libjvm.so+0x81383f]  os::Linux::commit_memory_impl(char*, unsigned
>> long, unsigned long, bool)+0x4f
>> V  [libjvm.so+0x813a2c]  os::pd_commit_memory(char*, unsigned long,
>> unsigned long, bool)+0xc
>> V  [libjvm.so+0x80daea]  os::commit_memory(char*, unsigned long,
>> unsigned long, bool)+0x2a
>> V  [libjvm.so+0x98e849]  VirtualSpace::expand_by(unsigned long,
>> bool)+0x1c9
>> V  [libjvm.so+0x58a62c]  CodeHeap::expand_by(unsigned long)+0x8c
>> V  [libjvm.so+0x42111d]  CodeCache::allocate(int)+0x4d
>> V  [libjvm.so+0x7e1a39]  nmethod::new_nmethod(methodHandle, int, int,
>> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
>> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
>> ImplicitExceptionTable*, AbstractCompiler*, int)+0x179
>> V  [libjvm.so+0x3cfc54]  ciEnv::register_method(ciMethod*, int,
>> CodeOffsets*, int, CodeBuffer*, int, OopMapSet*,
>> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,
>> int, bool, bool)+0x364
>> V  [libjvm.so+0x4458fb]  Compile::Compile(ciEnv*, C2Compiler*,
>> ciMethod*, int, bool, bool)+0x11cb
>> V  [libjvm.so+0x3afa76]  C2Compiler::compile_method(ciEnv*, ciMethod*,
>> int)+0x176
>> V  [libjvm.so+0x44ba9e]
>>  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x33e
>> V  [libjvm.so+0x44c87d]  CompileBroker::compiler_thread_loop()+0x43d
>> V  [libjvm.so+0x94d5ff]  JavaThread::thread_main_inner()+0xdf
>> V  [libjvm.so+0x94d705]  JavaThread::run()+0xf5
>> V  [libjvm.so+0x815538]  java_start(Thread*)+0x108
>>
>> Code Cache  [0x00002b091755c000, 0x00002b091869c000, 0x00002b091a55c000)
>>  total_blobs=7033 nmethods=6349 adapters=634 free_code_cache=31715Kb
>> largest_free_block=32247296
>>
>> Memory mappings around the code cache virtual space (bolded line is
>> the code cache segment, I believe, based on the Code Cache output above):
>>
>> *2b091755c000-2b091869c000 rwxp 00000000 00:00 0*
>> 2b09186ac000-2b091d66f000 rw-p 00000000 00:00 0
>> 2b091d66f000-2b091d670000 ---p 00000000 00:00 0
>> 2b091d670000-2b091d770000 rwxp 00000000 00:00 0
>> 2b091d770000-2b091d771000 ---p 00000000 00:00 0
>> 2b091d771000-2b091d871000 rwxp 00000000 00:00 0
>> 2b091d871000-2b091d872000 ---p 00000000 00:00 0
>> 2b091d872000-2b091d972000 rwxp 00000000 00:00 0
>>
>> /proc/meminfo:
>> MemTotal:       49521668 kB
>> MemFree:         5596796 kB
>> Buffers:          294684 kB
>> Cached:         34205856 kB
>> SwapCached:            0 kB
>> Active:         12745128 kB
>> Inactive:       28516788 kB
>> Active(anon):    9280636 kB
>> Inactive(anon):  3090264 kB
>> Active(file):    3464492 kB
>> Inactive(file): 25426524 kB
>> Unevictable:       14420 kB
>> Mlocked:           14420 kB
>> SwapTotal:             0 kB
>> SwapFree:              0 kB
>> Dirty:             20392 kB
>> Writeback:             0 kB
>> AnonPages:       6776540 kB
>> Mapped:          6292204 kB
>> Shmem:           5604620 kB
>> Slab:            1828656 kB
>> SReclaimable:    1567928 kB
>> SUnreclaim:       260728 kB
>> KernelStack:        4648 kB
>> PageTables:        58800 kB
>> NFS_Unstable:          0 kB
>> Bounce:                0 kB
>> WritebackTmp:          0 kB
>> CommitLimit:    47045584 kB
>> Committed_AS:   46046480 kB
>> VmallocTotal:   34359738367 kB
>> VmallocUsed:      460188 kB
>> VmallocChunk:   34333703480 kB
>> HugePages_Total:       0
>> HugePages_Free:        0
>> HugePages_Rsvd:        0
>> HugePages_Surp:        0
>> Hugepagesize:       2048 kB
>> DirectMap4k:        8192 kB
>> DirectMap2M:     2080768 kB
>> DirectMap1G:    48234496 kB
>>
>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>
>> * overcommit is turned off
>>
>> So the code heap was attempting to expand by 65kb at a fixed address.
>>  There appears to be a 65kb mapping available between the end of the
>> current code heap mapping (2b091755c000-2b091869c000) and the next one
>> (2b09186ac000-2b091d66f000).  There's about 30mb of free space left
>> (reserved, but uncommitted I take it) in the virtual space, so it's a
>> bit puzzling given there's ample physical mem available.  Only thing I
>> can think of is expansion fails because it cannot get contiguous
>> space, but then I can't reconcile that with the mem mapping above.
>>
>> Does anyone have any ideas?
>>
>> Let me know if you need additional info from the hs_err file.
>>
>> Thanks
>>
>

From vladimir.kozlov at oracle.com  Fri May 30 01:06:49 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 29 May 2014 18:06:49 -0700
Subject: Request for tracking down C1 optimizations: handwritten cartesian
	product similar to flatmap/map performance!
In-Reply-To: <5387766D.3020207@redhat.com>
References: <CAHLSyCko2tnaRhL8pEp1Oiwy2KM+AnhC1R7HSUAJc1hueSN6LQ@mail.gmail.com>
	<5387766D.3020207@redhat.com>
Message-ID: <5387D9A9.1090201@oracle.com>

Hi Aggelos,

Escape Analysis may not help you because main time goes to the loop 
which only reads from arrays and does math. There is no allocations in 
the loop. If stream version produces the same loop shape, the 
performance will be the same. We have -XX:+TraceLoopOpts flag but it is 
available only in debug version of JVM.

Vladimir

On 5/29/14 11:03 AM, Andrew Haley wrote:
> Hi,
>
> On 05/29/2014 06:55 PM, Aggelos Biboudis wrote:
>
>> I would like to ask you something regarding C1 compilation (VM options:
>> -Xms769m -Xmx769m -XX:-TieredCompilation)
>
> That's C2 compilation.
>
>> of a Cartesian product stream
>> operation with the new stream API.
>> I have two versions of this computation, one handwritten and one with
>> flatmap/map. It is remarkable that these two have similar performance so I
>> would like to trace-back the JIT compilation decisions (apart from
>> inlining), and more specifically if escape analysis has any effect.
>
> Are you quite sure your numbers aren't dominated by cache misses?  Your
> data is about 40 Megabytes and it's being accessed sequentially.
>
>> I've tested the code above with -XX:-DoEscapeAnalysis and I've got the same
>> execution times, however I would like to confirm what happens.
>> Regarding inlining, only by noticing the result of PrintInlining we
>> conclude that cartSeq inlines all the nested forEachRemaining operations
>> (of of, flatmap, map), but is that the only optimization?
>
> Not if this really is C2, no.  There are many optimization passes,
> and several will be effective for this code.
>
> Andrew.
>

From vitalyd at gmail.com  Fri May 30 01:20:13 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 29 May 2014 21:20:13 -0400
Subject: CodeHeap::expand_by malloc failed
In-Reply-To: <5387D545.9080404@oracle.com>
References: <CAHjP37Ea3=tpCUSMnbx4pLrXbWGjXTb19BSD23uJUCgFSwC8ow@mail.gmail.com>
	<E2B85BDE-7F4B-4025-B29E-AFD1AEBCE17D@oracle.com>
	<5387D545.9080404@oracle.com>
Message-ID: <CAHjP37EcnirJ1LoiG0UeLzOTi0uatgb--acFOJowOfGT-FMvdA@mail.gmail.com>

Yes, swap and overcommit are turned off.  But, there's substantial free
physical memory available and looks like 65kb available to expand the code
heap contiguoisly.  So I'm a bit puzzled ...

Taking Chris' suggestion and cc'ing hotspot dev ...

Sent from my phone
On May 29, 2014 8:47 PM, "Vladimir Kozlov" <vladimir.kozlov at oracle.com>
wrote:

> Could be because there is no swap on this machine:
>
> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>
> Vladimir
>
> On 5/29/14 5:35 PM, Christian Thalinger wrote:
>
>> Although it?s the code cache I assume runtime folk would know more about
>> this.  Maybe send to hotspot-dev.
>>
>> On May 29, 2014, at 9:01 AM, Vitaly Davidovich <vitalyd at gmail.com
>> <mailto:vitalyd at gmail.com>> wrote:
>>
>>  Hi guys,
>>>
>>> Need a bit of help explaining a hotspot malloc failure crash on 7u51.
>>>  I'm going to paste the relevant snippets from the hs_err log.
>>>
>>> #
>>> # There is insufficient memory for the Java Runtime Environment to
>>> continue.
>>> # Native memory allocation (malloc) failed to allocate 65536 bytes for
>>> committing reserved memory.
>>> # Possible reasons:
>>> #   The system is out of physical RAM or swap space
>>> #   In 32 bit mode, the process size limit was hit
>>> # Possible solutions:
>>> #   Reduce memory load on the system
>>> #   Increase physical memory or swap space
>>> #   Check if swap backing store is full
>>> #   Use 64 bit Java on a 64 bit OS
>>> #   Decrease Java heap size (-Xmx/-Xms)
>>> #   Decrease number of Java threads
>>> #   Decrease Java thread stack sizes (-Xss)
>>> #   Set larger code cache with -XX:ReservedCodeCacheSize=
>>> # This output file may be truncated or incomplete.
>>> #
>>> #  Out of Memory Error (os_linux.cpp:2726), pid=10643, tid=47319048501520
>>> #
>>> # JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build
>>> 1.7.0_51-b13)
>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode
>>> linux-amd64 compressed oops)
>>>
>>>
>>> ---------------  T H R E A D  ---------------
>>>
>>> Current thread (0x0000000000716800):  JavaThread "C2 CompilerThread0"
>>> daemon [_thread_in_vm, id=10689,
>>> stack(0x00002b095303b000,0x00002b095313c000)]
>>>
>>> Stack: [0x00002b095303b000,0x00002b095313c000],
>>>  sp=0x00002b0953138d20,  free space=1015k
>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>> C=native code)
>>> V  [libjvm.so+0x992f4a]  VMError::report_and_die()+0x2ea
>>> V  [libjvm.so+0x4931ab]  report_vm_out_of_memory(char const*, int,
>>> unsigned long, char const*)+0x9b
>>> V  [libjvm.so+0x81338e]  os::Linux::commit_memory_impl(char*, unsigned
>>> long, bool)+0xfe
>>> V  [libjvm.so+0x81383f]  os::Linux::commit_memory_impl(char*, unsigned
>>> long, unsigned long, bool)+0x4f
>>> V  [libjvm.so+0x813a2c]  os::pd_commit_memory(char*, unsigned long,
>>> unsigned long, bool)+0xc
>>> V  [libjvm.so+0x80daea]  os::commit_memory(char*, unsigned long,
>>> unsigned long, bool)+0x2a
>>> V  [libjvm.so+0x98e849]  VirtualSpace::expand_by(unsigned long,
>>> bool)+0x1c9
>>> V  [libjvm.so+0x58a62c]  CodeHeap::expand_by(unsigned long)+0x8c
>>> V  [libjvm.so+0x42111d]  CodeCache::allocate(int)+0x4d
>>> V  [libjvm.so+0x7e1a39]  nmethod::new_nmethod(methodHandle, int, int,
>>> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
>>> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
>>> ImplicitExceptionTable*, AbstractCompiler*, int)+0x179
>>> V  [libjvm.so+0x3cfc54]  ciEnv::register_method(ciMethod*, int,
>>> CodeOffsets*, int, CodeBuffer*, int, OopMapSet*,
>>> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,
>>> int, bool, bool)+0x364
>>> V  [libjvm.so+0x4458fb]  Compile::Compile(ciEnv*, C2Compiler*,
>>> ciMethod*, int, bool, bool)+0x11cb
>>> V  [libjvm.so+0x3afa76]  C2Compiler::compile_method(ciEnv*, ciMethod*,
>>> int)+0x176
>>> V  [libjvm.so+0x44ba9e]
>>>  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x33e
>>> V  [libjvm.so+0x44c87d]  CompileBroker::compiler_thread_loop()+0x43d
>>> V  [libjvm.so+0x94d5ff]  JavaThread::thread_main_inner()+0xdf
>>> V  [libjvm.so+0x94d705]  JavaThread::run()+0xf5
>>> V  [libjvm.so+0x815538]  java_start(Thread*)+0x108
>>>
>>> Code Cache  [0x00002b091755c000, 0x00002b091869c000, 0x00002b091a55c000)
>>>  total_blobs=7033 nmethods=6349 adapters=634 free_code_cache=31715Kb
>>> largest_free_block=32247296
>>>
>>> Memory mappings around the code cache virtual space (bolded line is
>>> the code cache segment, I believe, based on the Code Cache output above):
>>>
>>> *2b091755c000-2b091869c000 rwxp 00000000 00:00 0*
>>> 2b09186ac000-2b091d66f000 rw-p 00000000 00:00 0
>>> 2b091d66f000-2b091d670000 ---p 00000000 00:00 0
>>> 2b091d670000-2b091d770000 rwxp 00000000 00:00 0
>>> 2b091d770000-2b091d771000 ---p 00000000 00:00 0
>>> 2b091d771000-2b091d871000 rwxp 00000000 00:00 0
>>> 2b091d871000-2b091d872000 ---p 00000000 00:00 0
>>> 2b091d872000-2b091d972000 rwxp 00000000 00:00 0
>>>
>>> /proc/meminfo:
>>> MemTotal:       49521668 kB
>>> MemFree:         5596796 kB
>>> Buffers:          294684 kB
>>> Cached:         34205856 kB
>>> SwapCached:            0 kB
>>> Active:         12745128 kB
>>> Inactive:       28516788 kB
>>> Active(anon):    9280636 kB
>>> Inactive(anon):  3090264 kB
>>> Active(file):    3464492 kB
>>> Inactive(file): 25426524 kB
>>> Unevictable:       14420 kB
>>> Mlocked:           14420 kB
>>> SwapTotal:             0 kB
>>> SwapFree:              0 kB
>>> Dirty:             20392 kB
>>> Writeback:             0 kB
>>> AnonPages:       6776540 kB
>>> Mapped:          6292204 kB
>>> Shmem:           5604620 kB
>>> Slab:            1828656 kB
>>> SReclaimable:    1567928 kB
>>> SUnreclaim:       260728 kB
>>> KernelStack:        4648 kB
>>> PageTables:        58800 kB
>>> NFS_Unstable:          0 kB
>>> Bounce:                0 kB
>>> WritebackTmp:          0 kB
>>> CommitLimit:    47045584 kB
>>> Committed_AS:   46046480 kB
>>> VmallocTotal:   34359738367 kB
>>> VmallocUsed:      460188 kB
>>> VmallocChunk:   34333703480 kB
>>> HugePages_Total:       0
>>> HugePages_Free:        0
>>> HugePages_Rsvd:        0
>>> HugePages_Surp:        0
>>> Hugepagesize:       2048 kB
>>> DirectMap4k:        8192 kB
>>> DirectMap2M:     2080768 kB
>>> DirectMap1G:    48234496 kB
>>>
>>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>>
>>> * overcommit is turned off
>>>
>>> So the code heap was attempting to expand by 65kb at a fixed address.
>>>  There appears to be a 65kb mapping available between the end of the
>>> current code heap mapping (2b091755c000-2b091869c000) and the next one
>>> (2b09186ac000-2b091d66f000).  There's about 30mb of free space left
>>> (reserved, but uncommitted I take it) in the virtual space, so it's a
>>> bit puzzling given there's ample physical mem available.  Only thing I
>>> can think of is expansion fails because it cannot get contiguous
>>> space, but then I can't reconcile that with the mem mapping above.
>>>
>>> Does anyone have any ideas?
>>>
>>> Let me know if you need additional info from the hs_err file.
>>>
>>> Thanks
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140529/20b53a5e/attachment.html>

From vladimir.kozlov at oracle.com  Fri May 30 02:00:33 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 29 May 2014 19:00:33 -0700
Subject: Regarding 8033626: C2: Merging exception state: reexecute=true
	vs reexecute=false
In-Reply-To: <5386FA8E.6010901@oracle.com>
References: <538610B9.6060008@oracle.com> <5386609F.7030206@oracle.com>
	<5386FA8E.6010901@oracle.com>
Message-ID: <5387E641.3090508@oracle.com>

Now I understand the problem. I think we need to keep separate an 
exception code which requires re-execution. Currently we don't check for 
should_reexecute() when we merge or search for existing exception code 
(we only compare type).

Vladimir K.

On 5/29/14 2:14 AM, Vladimir Ivanov wrote:
> The problem is with exception state of two branches [1].
> Exception on fast path comes from GraphKit::new_instance during
> intrinsic construction in LibraryCallKit::inline_native_clone. It is
> executed under should_reexecute=true. PreserveReexecuteState doesn't
> touch exception state, so kit.add_exception_states_from(new_jvms) (@
> callGenerator.cpp:703) tries to accumulate incompatible exceptions from
> fast & slow paths.
>
> Best regards,
> Vladimir Ivanov
>
> [1] FAST PATH (intrinsic):
>
> JVMS depth=1 loc=5 stk=9 arg=10 mon=14 scalar=14 end=14 mondepth=0 sp=1
> bci=12 reexecute=false method=virtual jobject
>
> Exception state:
>
> JVMS depth=1 loc=5 stk=9 arg=9 mon=14 scalar=14 end=14 mondepth=0 sp=0
> bci=12 reexecute=true method=virtual jobject
>
> SLOW PATH
>
> JVMS depth=1 loc=5 stk=9 arg=10 mon=14 scalar=14 end=14 mondepth=0 sp=1
> bci=12 reexecute=false method=virtual jobject
>
> Exception state:
>
> JVMS depth=1 loc=5 stk=9 arg=9 mon=14 scalar=14 end=14 mondepth=0 sp=0
> bci=12 reexecute=false method=virtual jobject
>
>
> On 5/29/14 2:18 AM, Vladimir Kozlov wrote:
>> PredictedIntrinsicGenerator was added to have a general predicate. For
>> example, AES crypto predicate checks klass of an object pointed by a
>> field. PredictedCallGenerator checks klass of method's holder only.
>>
>> Both cases would have the same problem with reexecute. Using
>> PredictedIntrinsicGenerator will not help you.
>>
>> But you should not have this problem at the merge point, because
>> reexecute should be reset back after intrinsic is generated:
>>
>>    { PreserveReexecuteState preexecs(this);
>>      jvms()->set_should_reexecute(true);
>>
>> It is strange that it is still true after PreserveReexecuteState
>> destructor.
>>
>> Vladimir K
>>
>> On 5/28/14 9:37 AM, Vladimir Ivanov wrote:
>>> Hi,
>>>
>>> I'm looking at 8033626 [1]:
>>> "assert(ex_map->jvms()->same_calls_as(_exceptions->jvms())) failed: all
>>> collected exceptions must come from the same place".
>>>
>>> 8014447 [2] introduced new code shape for virtual intrinsifiable methods
>>> (Object::hashCode & Object::clone): "invokevirtual Object.clone()" can
>>> be represented as a PredictedCallGenerator with LibraryIntrinsic on fast
>>> path and VirtualCallGenerator on slow path.
>>>
>>> The problem arises for Object::clone, because for OOM case intrinsified
>>> version requires reexecution (reexecute=true), but slow path (virtual
>>> dispatch) doesn't (reexecute=false). Further attempt to finish the
>>> diamond and merge 2 exception states fires the assertion.
>>>
>>> So, I have 2 questions:
>>>    (1) I don't see any way to merge reexecute=true & reexecute=false
>>> states, so both branches should have the same reexecute status. Am I
>>> missing something?
>>>
>>>    (2) Does PredictedCallGenerator actually support such shape
>>> (intrinsic on fast path)? There are 2 call generators:
>>> PredictedIntrinsicGenerator & PredictedCallGenerator. What's the
>>> difference?
>>>
>>> I see there's a way to customize predicate in
>>> LibraryCallKit::try_to_predicate() for PredictedIntrinsicGenerator, but
>>> is it the only reason why PredictedIntrinsicGenerator was introduced?
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8033626
>>>
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8014447
>>>      "Object.hashCode intrinsic breaks inline caches"

From albert.noll at oracle.com  Fri May 30 04:45:59 2014
From: albert.noll at oracle.com (Albert)
Date: Fri, 30 May 2014 06:45:59 +0200
Subject: [8u20,
	9] RFR(S): 8011646	: SEGV in compiled code with loop predication
In-Reply-To: <5387ADC3.80200@oracle.com>
References: <5386361E.8020903@oracle.com>	<9401C93A-028E-40D5-BBBA-85B2B61CD73A@oracle.com>	<538657D1.3020706@oracle.com>	<53865ADA.7070208@oracle.com>	<31BFB28F-6A42-4FAC-B721-F4D0484FF474@oracle.com>	<53868D80.5030303@oracle.com>	<538787DE.2090901@oracle.com>
	<5387ADC3.80200@oracle.com>
Message-ID: <53880D07.5040005@oracle.com>

Hi Vladimir,

thanks for your answer. I will push it then.

Best,
Albert

On 05/29/2014 11:59 PM, Vladimir Kozlov wrote:
>
> On 5/29/14 12:17 PM, Albert wrote:
>> John, Vladimir, thanks for your comments.
>>
>> How shall we proceed with this bug? Is it OK to push this change?
>> Shall I file an RFE that suggests to further investigate possible issues
>> at the places that Vladimir mentioned?
>
> I think we need to do only point fix in inline_native_hashcode() now 
> and file RFE to investigate other cases (including Parse::array_load() 
> as Roland pointed). May be find general solution when we have 
> dependency on several controls. Actually we already have BUG for this:
>
> https://bugs.openjdk.java.net/browse/JDK-6831314
>
> I can assigned it to you, Albert, if you want.
>
> Thanks,
> Vladimir
>
>>
>> Best,
>> Albert
>>
>>
>> On 05/29/2014 03:29 AM, Vladimir Kozlov wrote:
>>> On 5/28/14 4:42 PM, John Rose wrote:
>>>> On May 28, 2014, at 2:53 PM, Albert <albert.noll at oracle.com
>>>> <mailto:albert.noll at oracle.com>> wrote:
>>>>
>>>>>> It is only 'Node *' to 'Node* ' change. 'udiffs' show that cleanly.
>>>>>>
>>>>> Yes, I just put the '*' uniformly to the left side.
>>>>
>>>> (Which is fine BTW, since the majority usage is "T* x" not "T *x";
>>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide points out we
>>>> do such adjustments.)
>>>>
>>>> Are there any other places where C2 uses normal IR to access the mark
>>>> word of an object, and if so, is a similar bug fix needed there?  
>>>> If so,
>>>> the tricky logic for building the free-standing LoadXNode needs to be
>>>> factored into a subroutine.
>>>
>>> There are several places in macro.cpp in expand_lock_node() and
>>> expand_unlock_node() which takes control. Note, LockNode is call node
>>> and always has control. I thought about this part yesterday but said
>>> nothing because we did not have any problems with that code before.
>>> And we need more testing if we remove these control edges.
>>>
>>> Originally these loads were RAW memory operations and required to have
>>> control to prevent skipping safepoints.
>>>
>>> Vladimir
>>>
>>>>
>>>> ? John
>>


From tobias.hartmann at oracle.com  Fri May 30 06:58:14 2014
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 30 May 2014 08:58:14 +0200
Subject: [9] RFR(S): 8021775: compiler/8009761/Test8009761.java "Failed:
	init recursive calls: 51. After deopt 50"
In-Reply-To: <BED42C73-3891-4B95-9495-0FE1D5FB39A2@oracle.com>
References: <5374B6C1.5010903@oracle.com>	<63F41E25-1ECA-46A4-A6C5-6187EAE79AD2@oracle.com>	<5375F6A3.3010307@oracle.com>	<D200E44A-EFEB-4772-A1DA-1B3FA6637D87@oracle.com>
	<5385ACF8.2020609@oracle.com> <5385BB4B.2040903@oracle.com>
	<5385BE58.10303@oracle.com> <5385C06F.5090408@oracle.com>
	<5385C244.4010901@oracle.com>
	<BED42C73-3891-4B95-9495-0FE1D5FB39A2@oracle.com>
Message-ID: <53882C06.9030304@oracle.com>

Roland, Chris, thanks for the reviews.

Best,
Tobias

On 28.05.2014 22:49, Christian Thalinger wrote:
> Looks good.  Thanks!
>
> On May 28, 2014, at 4:02 AM, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>
>> On 28.05.2014 12:54, Igor Ignatyev wrote:
>>> Thanks.
>>>
>>> Could you please also replace System::exit by throwing an exception?
>>>> 277             System.exit(97);
>> Done:
>>
>> http://cr.openjdk.java.net/~anoll/8021775/webrev.03/
>>
>> Thanks,
>> Tobias
>>
>>> Igor
>>>
>>> On 05/28/2014 02:45 PM, Tobias Hartmann wrote:
>>>> Hi Igor,
>>>>
>>>> On 28.05.2014 12:32, Igor Ignatyev wrote:
>>>>> Hi Tobias,
>>>>>
>>>>> Since now the test uses JMX, you have to add it into needs_compact3
>>>>> group in 'test/TEST.groups'.
>>>> Done. New webrev:
>>>>
>>>> http://cr.openjdk.java.net/~anoll/8021775/webrev.02/
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>>
>>>>> Igor
>>>>>
>>>>> On 05/28/2014 01:31 PM, Tobias Hartmann wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>> thanks for the feedback.
>>>>>>
>>>>>> On 16.05.2014 18:00, Christian Thalinger wrote:
>>>>>>> On May 16, 2014, at 4:29 AM, Tobias Hartmann
>>>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>> wrote:
>>>>>>>
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>> thanks for the review.
>>>>>>>>
>>>>>>>> On 15.05.2014 16:31, Christian Thalinger wrote:
>>>>>>>>> Presumably:
>>>>>>>>> *+          WHITE_BOX.enqueueMethodForCompilation(m3,
>>>>>>>>> COMP_LEVEL_FULL_OPTIMIZATION);*
>>>>>>>>> *+          if(!WHITE_BOX.isMethodCompiled(m3)) {*
>>>>>>>>> *+             throw new RuntimeException(m3 + " not compiled");*
>>>>>>>>>            }
>>>>>>>>> works because we?re using -XX:-BackgroundCompilation, correct?
>>>>>>>>> Maybe add a comment there.
>>>>>>>> Yes, exactly.
>>>>>>>>
>>>>>>>>> Can we verify via WB API that BackgroundCompilation is off?
>>>>>>>> Yes, this is for example done in
>>>>>>>> CompilerWhiteBoxTest::getVMOption(...) to set BACKGROUND_COMPILATION.
>>>>>>>> But I think because we explicitly disable background compilation in
>>>>>>>> the test header it should not be possible to re-enable it, right?
>>>>>>> Correct but who knows what test cleanup might happen in the future.
>>>>>>> Maybe someday someone decides that we shouldn?t run tests with
>>>>>>> -BackgroundCompilation.  This test is not easy to get right and had a
>>>>>>> couple of issues already.  I want it fool proof.
>>>>>> Right. I added a method backgroundCompilationEnabled(...) to check if
>>>>>> background compilation is enabled and explicitly check it in main.
>>>>>>
>>>>>> New webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.01/
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>>
>>>>>>>>> I?m happy that using the WB API worked.
>>>>>>>>>
>>>>>>>>> On May 15, 2014, at 5:44 AM, Tobias Hartmann
>>>>>>>>> <tobias.hartmann at oracle.com <mailto:tobias.hartmann at oracle.com>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> please review the following patch for 8021775.
>>>>>>>>>>
>>>>>>>>>> *Problem
>>>>>>>>>> *The compiler test for bug 8009761 checks if the stack size after
>>>>>>>>>> deoptimization is the same as before by counting the number of
>>>>>>>>>> possible recursive calls until a StackOverflowException occurs both
>>>>>>>>>> before and after deoptimization. The test tries to trigger
>>>>>>>>>> compilation by executing the method multiple times and enforces
>>>>>>>>>> deoptimization by loading a previously unloaded class.
>>>>>>>>>>
>>>>>>>>>> The test fails on multiple platforms.*
>>>>>>>>>> *Bug: https://bugs.openjdk.java.net/browse/JDK-8021775
>>>>>>>>>>
>>>>>>>>>> *Solution**
>>>>>>>>>> *The test seems to be unstable, as there already occurred several
>>>>>>>>>> test bugs (see 8010399 and 8012037). Enforcing compilation by
>>>>>>>>>> executing a method multiple times is indeterministic. We have to
>>>>>>>>>> make sure that the method is compiled and deoptimized exactly at
>>>>>>>>>> those points in time where it is needed.
>>>>>>>>>>
>>>>>>>>>> I reimplemented the test using the Whitebox API to
>>>>>>>>>> deterministically trigger compilation and deoptimization.
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~anoll/8021775/webrev.00/
>>>>>>>>>> *
>>>>>>>>>> **Tests*
>>>>>>>>>> Executed test on machines where it previously failed (1k runs, no
>>>>>>>>>> fails).
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Tobias


From paul.sandoz at oracle.com  Fri May 30 08:40:17 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 30 May 2014 10:40:17 +0200
Subject: Request for tracking down C1 optimizations: handwritten cartesian
	product similar to flatmap/map performance!
In-Reply-To: <CAHLSyCko2tnaRhL8pEp1Oiwy2KM+AnhC1R7HSUAJc1hueSN6LQ@mail.gmail.com>
References: <CAHLSyCko2tnaRhL8pEp1Oiwy2KM+AnhC1R7HSUAJc1hueSN6LQ@mail.gmail.com>
Message-ID: <3F26DFBF-0D5C-466C-BF8D-307772516835@oracle.com>

On May 29, 2014, at 7:55 PM, Aggelos Biboudis <biboudis at gmail.com> wrote:
> Hello all,
> 
> I would like to ask you something regarding C1 compilation (VM options: -Xms769m -Xmx769m -XX:-TieredCompilation) of a Cartesian product stream operation with the new stream API. 
> I have two versions of this computation, one handwritten and one with flatmap/map. It is remarkable that these two have similar performance so I would like to trace-back the JIT compilation decisions (apart from inlining), and more specifically if escape analysis has any effect.
> 
> ...
> 
> valuesHi = IntStream.range(0, 10000).mapToLong(i -> i).toArray();
> valuesLo = IntStream.range(0, 1000).mapToLong(i -> i).toArray();
> 

Tip: you can also use LongStream.range(0, N).toArray();


> @GenerateMicroBenchmark // -> 4.984 ms / op on avg
> public long cartSeq() {
>    long cart
>          = LongStream.of(valuesHi)
>             .flatMap(d -> LongStream.of(valuesLo).map(dP -> dP * d))

The function of long -> LongStream passed to the flatMap operation will create two objects per call: an instance of LongStream; and an instance of Spliterator. The map operation is passed a capturing lambda so on each call it will create an instance of LongUnaryOperator.

My hunch was, unless there is something else dominating, there some form of scalar replacement is going on. However, is it reasonable to assume that the difference of 700us is due to the cost of object allocations? To be sure one would need to look at the generated code.

To factor out array reads you might want to measure:

        long cart
                = LongStream.range(0, 10000)
                .flatMap(d -> LongStream.range(0, 1000).map(dP -> dP * d))
                .sum();

Paul.



>             .sum();       
>    return cart;
> }
> 
> @GenerateMicroBenchmark // -> 4.258 ms / op on avg
> public long cartBaseline() { 
>     long cart = 0;
>     for (int d = 0 ; d < valuesHi.length ; d++) {
>         for (int dp = 0 ; dp < valuesLo.length ; dp++){
>         cart += valuesHi[d] * valuesLo[dp];
>         }
>     }
>     return cart;
> }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140530/be1d25ba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140530/be1d25ba/signature.asc>

From igor.ignatyev at oracle.com  Fri May 30 09:01:23 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 30 May 2014 13:01:23 +0400
Subject: RFR(S) : 8038756 : new WB API :: get/setVMFlag
In-Reply-To: <4F499D2F-C30C-421F-89A3-6AC3BF1F99D5@oracle.com>
References: <53388795.9070005@oracle.com> <533A892C.2090208@oracle.com>
	<330EABDB-3376-4559-A077-2FD853D3C0FA@oracle.com>
	<533ACC52.4000000@oracle.com>
	<5EB6C74E-71DC-47DF-A961-053C39C1B3B4@oracle.com>
	<533BF65C.8080509@oracle.com>
	<4F499D2F-C30C-421F-89A3-6AC3BF1F99D5@oracle.com>
Message-ID: <538848E3.7080106@oracle.com>

On 04/02/2014 03:46 PM, Staffan Larsen wrote:
>
> On 2 apr 2014, at 13:37, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>
>> Staffan,
>>
>> I'd like not to have verifying of flags' value in these WB methods. Since it's a "Unsupported internal testing API", we don't have to have them.
>
> That could work. Until someone uses the WB Api to change some flag that really should cause other flags to be updated as well. But I?ll guess we can take that problem when it comes.
>
>> Also I'd like to have a possibility to change even "readonly" flags, which is against verifying logic I guess, e.g. UseCodeCacheFlushing for stress testing of code cache (JDK-8028595).
>
> Changing a flag that is not meant to be changed at runtime (not marked as ?manageable? or ?read_write') could cause problems. For example if having the flag set requires some init code to have been run. If the flag is safe for changing at runtime, can?t you just mark it as read_write?
Again, since WB API is a "Unsupported internal testing API", I think 
it's ok to get such problems. Moreover, it can be a valid test scenario, 
e.g. change flags which ain't supposed to be changed and get a crash.
> /Staffan
>
>>
>> Thanks
>> Igor
>>
>> On 04/02/2014 02:27 PM, Staffan Larsen wrote:
>>>
>>> On 1 apr 2014, at 16:25, Lev Priima <lev.priima at oracle.com> wrote:
>>>
>>>> Staffan,
>>>>
>>>> sun.tools.* API(as well as all tools.jar) does not present in compact1 profile.
>>>
>>> I see, that?s a reason to add this. However, do we really need to test this specifically on compact1? I?m not sure what tests you are planning to use this feature for, but if it is for testing code that we don?t believe is special for compact1, then I?m not sure we need to run the tests on compact1. Maybe a stupid optimization.
>>>
>>> One larger problem here is that this introduced yet another way to set the flags. So far we have three other ways: attachListener.cpp, management.cpp, and arguments.cpp. Currently these three all have duplicated code for verifying the consistency of some of the flags. See the calls to Arguments::verify_MinHeapFreeRatio() for example. If we add yet another way, then that code needs to be copied again. I didn?t like the copying in the first place, but allowed it because we were too lazy at that point to refactor the code? At this point, however, I would like to see that duplication taken care of before we add another way to set the flags. I?m sorry that this is going to make this change harder for you, but we really should only have that code in one place.
>>>
>>> /Staffan
>>>
>>>
>>>>
>>>> Lev
>>>>
>>>> On 04/01/2014 05:02 PM, Staffan Larsen wrote:
>>>>> There is already an API for getting / setting flags in sun.tools.attach.HotSpotVirtualMachine. If at all possible, we should reuse that API instead of adding a new one.
>>>>>
>>>>> Typical use:
>>>>>
>>>>> HotSpotVirtualMachine vm = (HotSpotVirtualMachine) VirtualMachine.attach(pid);
>>>>> vm.setFlag(?MyFlag?, ?MyValue?);
>>>>>
>>>>> There is also an API in sun.management.HotSpotDiagnostic for setting / getting as well as querying for options in JVM.
>>>>>
>>>>> Thanks,
>>>>> /Staffan
>>>>>
>>>>>
>>>>> On 1 apr 2014, at 11:38, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>
>>>>>> adding hotspot-dev alias.
>>>>>>
>>>>>> On 03/31/2014 01:07 AM, Igor Ignatyev wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Please review the patch which introduces new WhiteBox methods to get and
>>>>>>> set VM flags.
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/
>>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038756
>>>>>>> testing: jprt
>>>>
>>>
>

From staffan.larsen at oracle.com  Fri May 30 09:42:55 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 30 May 2014 11:42:55 +0200
Subject: RFR(S) : 8038756 : new WB API :: get/setVMFlag
In-Reply-To: <538848E3.7080106@oracle.com>
References: <53388795.9070005@oracle.com> <533A892C.2090208@oracle.com>
	<330EABDB-3376-4559-A077-2FD853D3C0FA@oracle.com>
	<533ACC52.4000000@oracle.com>
	<5EB6C74E-71DC-47DF-A961-053C39C1B3B4@oracle.com>
	<533BF65C.8080509@oracle.com>
	<4F499D2F-C30C-421F-89A3-6AC3BF1F99D5@oracle.com>
	<538848E3.7080106@oracle.com>
Message-ID: <2A4E2CEF-4C19-45F2-BEAD-1E52A937C681@oracle.com>


On 30 maj 2014, at 11:01, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:

> On 04/02/2014 03:46 PM, Staffan Larsen wrote:
>> 
>> On 2 apr 2014, at 13:37, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>> 
>>> Staffan,
>>> 
>>> I'd like not to have verifying of flags' value in these WB methods. Since it's a "Unsupported internal testing API", we don't have to have them.
>> 
>> That could work. Until someone uses the WB Api to change some flag that really should cause other flags to be updated as well. But I?ll guess we can take that problem when it comes.
>> 
>>> Also I'd like to have a possibility to change even "readonly" flags, which is against verifying logic I guess, e.g. UseCodeCacheFlushing for stress testing of code cache (JDK-8028595).
>> 
>> Changing a flag that is not meant to be changed at runtime (not marked as ?manageable? or ?read_write') could cause problems. For example if having the flag set requires some init code to have been run. If the flag is safe for changing at runtime, can?t you just mark it as read_write?
> Again, since WB API is a "Unsupported internal testing API", I think it's ok to get such problems. Moreover, it can be a valid test scenario, e.g. change flags which ain't supposed to be changed and get a crash.

Ok.

>> /Staffan
>> 
>>> 
>>> Thanks
>>> Igor
>>> 
>>> On 04/02/2014 02:27 PM, Staffan Larsen wrote:
>>>> 
>>>> On 1 apr 2014, at 16:25, Lev Priima <lev.priima at oracle.com> wrote:
>>>> 
>>>>> Staffan,
>>>>> 
>>>>> sun.tools.* API(as well as all tools.jar) does not present in compact1 profile.
>>>> 
>>>> I see, that?s a reason to add this. However, do we really need to test this specifically on compact1? I?m not sure what tests you are planning to use this feature for, but if it is for testing code that we don?t believe is special for compact1, then I?m not sure we need to run the tests on compact1. Maybe a stupid optimization.
>>>> 
>>>> One larger problem here is that this introduced yet another way to set the flags. So far we have three other ways: attachListener.cpp, management.cpp, and arguments.cpp. Currently these three all have duplicated code for verifying the consistency of some of the flags. See the calls to Arguments::verify_MinHeapFreeRatio() for example. If we add yet another way, then that code needs to be copied again. I didn?t like the copying in the first place, but allowed it because we were too lazy at that point to refactor the code? At this point, however, I would like to see that duplication taken care of before we add another way to set the flags. I?m sorry that this is going to make this change harder for you, but we really should only have that code in one place.
>>>> 
>>>> /Staffan
>>>> 
>>>> 
>>>>> 
>>>>> Lev
>>>>> 
>>>>> On 04/01/2014 05:02 PM, Staffan Larsen wrote:
>>>>>> There is already an API for getting / setting flags in sun.tools.attach.HotSpotVirtualMachine. If at all possible, we should reuse that API instead of adding a new one.
>>>>>> 
>>>>>> Typical use:
>>>>>> 
>>>>>> HotSpotVirtualMachine vm = (HotSpotVirtualMachine) VirtualMachine.attach(pid);
>>>>>> vm.setFlag(?MyFlag?, ?MyValue?);
>>>>>> 
>>>>>> There is also an API in sun.management.HotSpotDiagnostic for setting / getting as well as querying for options in JVM.
>>>>>> 
>>>>>> Thanks,
>>>>>> /Staffan
>>>>>> 
>>>>>> 
>>>>>> On 1 apr 2014, at 11:38, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>> 
>>>>>>> adding hotspot-dev alias.
>>>>>>> 
>>>>>>> On 03/31/2014 01:07 AM, Igor Ignatyev wrote:
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> Please review the patch which introduces new WhiteBox methods to get and
>>>>>>>> set VM flags.
>>>>>>>> 
>>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/
>>>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038756
>>>>>>>> testing: jprt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140530/f1924763/attachment.html>

From staffan.larsen at oracle.com  Fri May 30 12:08:10 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 30 May 2014 14:08:10 +0200
Subject: RFR(S): 8043915: Tests get ClassNotFoundException:
	com.oracle.java.testlibrary.StreamPumper
In-Reply-To: <5385CF6B.3090404@oracle.com>
References: <5385CF6B.3090404@oracle.com>
Message-ID: <8BB886AC-BD1E-42D2-8DCB-30BCEFFEF375@oracle.com>

Looks good!

Thanks,
/Staffan

On 28 maj 2014, at 13:58, Yekaterina Kantserova <yekaterina.kantserova at oracle.com> wrote:

> Hi,
> 
> Could I please have a review of this fix.
> 
> webrev: http://cr.openjdk.java.net/~ykantser/8043915/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8043915
> 
> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when for example running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together.
> 
> Verified locally.
> 
> Thanks,
> Katja


From vladimir.x.ivanov at oracle.com  Fri May 30 12:22:06 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 30 May 2014 16:22:06 +0400
Subject: RFR(S) : 8038756 : new WB API :: get/setVMFlag
In-Reply-To: <533A892C.2090208@oracle.com>
References: <53388795.9070005@oracle.com> <533A892C.2090208@oracle.com>
Message-ID: <538877EE.5080001@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 4/1/14 1:38 PM, Igor Ignatyev wrote:
> adding hotspot-dev alias.
>
> On 03/31/2014 01:07 AM, Igor Ignatyev wrote:
>> Hi all,
>>
>> Please review the patch which introduces new WhiteBox methods to get and
>> set VM flags.
>>
>> webrev: http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038756
>> testing: jprt

From biboudis at gmail.com  Fri May 30 12:48:17 2014
From: biboudis at gmail.com (Aggelos Biboudis)
Date: Fri, 30 May 2014 15:48:17 +0300
Subject: Request for tracking down C1 optimizations: handwritten cartesian
	product similar to flatmap/map performance!
In-Reply-To: <3F26DFBF-0D5C-466C-BF8D-307772516835@oracle.com>
References: <CAHLSyCko2tnaRhL8pEp1Oiwy2KM+AnhC1R7HSUAJc1hueSN6LQ@mail.gmail.com>
	<3F26DFBF-0D5C-466C-BF8D-307772516835@oracle.com>
Message-ID: <CAHLSyCkz1qjmhfPno=5PhARAWk97L0BvBXUQLZ21tVfXF=91Kg@mail.gmail.com>

The quick thing to do, was to produce the log including the generated code:

http://cgi.di.uoa.gr/~biboudis/hotspot_pid5379.log

These are what I know:

   - The execution happens inside copyInto
   - we have three forEachRemaining calls (of, flatMap, map) that are
   delegated via the accept methods of the wrapped sink.
   - the second lambda which is captured is obtained via a method
   internalMemberName

If scalar replacement happens I should expect to see the captured lambda
spilled on the stack and accessed accordingly when the execution reaches a
request to the reference of the mapper lambda inside flatMap. From what I
understand, this should have happened in the accept of flatMap where the
inner lambda is linked and more specifically "inside" the mapper.apply of
LongPipeline:286, right (in terms of runtime execution)? And even more
specifically when accepting the captured lambda (lambda$8 to my
understanding).

On a side note, I'll produce a debug build of the vm to examine this
better. ;-) Thx for the direction.

Aggelos.



On Fri, May 30, 2014 at 11:40 AM, Paul Sandoz <paul.sandoz at oracle.com>
wrote:

> On May 29, 2014, at 7:55 PM, Aggelos Biboudis <biboudis at gmail.com> wrote:
>
> Hello all,
>
> I would like to ask you something regarding C1 compilation (VM options:
> -Xms769m -Xmx769m -XX:-TieredCompilation) of a Cartesian product stream
> operation with the new stream API.
> I have two versions of this computation, one handwritten and one with
> flatmap/map. It is remarkable that these two have similar performance so I
> would like to trace-back the JIT compilation decisions (apart from
> inlining), and more specifically if escape analysis has any effect.
>
> ...
>>
>> valuesHi = IntStream.range(0, 10000).mapToLong(i -> i).toArray();
>> valuesLo = IntStream.range(0, 1000).mapToLong(i -> i).toArray();
>>
>>
> Tip: you can also use LongStream.range(0, N).toArray();
>
>
> @GenerateMicroBenchmark // -> 4.984 ms / op on avg
>> public long cartSeq() {
>>    long cart
>>          = LongStream.of(valuesHi)
>>             .flatMap(d -> LongStream.of(valuesLo).map(dP -> dP * d))
>>
>
> The function of long -> LongStream passed to the flatMap operation will
> create two objects per call: an instance of LongStream; and an instance of
> Spliterator. The map operation is passed a capturing lambda so on each call
> it will create an instance of LongUnaryOperator.
>
> My hunch was, unless there is something else dominating, there some form
> of scalar replacement is going on. However, is it reasonable to assume that
> the difference of 700us is due to the cost of object allocations? To be
> sure one would need to look at the generated code.
>
> To factor out array reads you might want to measure:
>
>         long cart
>                 = LongStream.range(0, 10000)
>                 .flatMap(d -> LongStream.range(0, 1000).map(dP -> dP * d))
>                 .sum();
>
> Paul.
>
>
>
>             .sum();
>>    return cart;
>> }
>>
>> @GenerateMicroBenchmark // -> 4.258 ms / op on avg
>> public long cartBaseline() {
>>     long cart = 0;
>>     for (int d = 0 ; d < valuesHi.length ; d++) {
>>         for (int dp = 0 ; dp < valuesLo.length ; dp++){
>>         cart += valuesHi[d] * valuesLo[dp];
>>         }
>>     }
>>     return cart;
>> }
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140530/c0052b7f/attachment-0001.html>

From peter.allwin at oracle.com  Fri May 30 12:08:45 2014
From: peter.allwin at oracle.com (Peter Allwin)
Date: Fri, 30 May 2014 14:08:45 +0200
Subject: RFR(S): 8043915: Tests get ClassNotFoundException:
	com.oracle.java.testlibrary.StreamPumper
In-Reply-To: <5385CF6B.3090404@oracle.com>
References: <5385CF6B.3090404@oracle.com>
Message-ID: <A6119B80-9FA9-43AB-8A92-F91FA5913EDD@oracle.com>

Hi Katja,

Is it necessary to @build classes used in @run statements? I see you added it to some but GetObjectSizeOverflow.java is missing ClassFileInstaller.


Other than that it looks good!

Thanks,
/peter


On 28 May 2014, at 13:58, Yekaterina Kantserova <yekaterina.kantserova at oracle.com> wrote:

> Hi,
> 
> Could I please have a review of this fix.
> 
> webrev: http://cr.openjdk.java.net/~ykantser/8043915/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8043915
> 
> When using @library in a JTreg test even @build need to be specify for all library files used by the test. If @build is not specified it can lead to intermittent failures when for example running tests concurrently, since javac implicit compilation and @library and -concurrency don't play well together.
> 
> Verified locally.
> 
> Thanks,
> Katja


From igor.ignatyev at oracle.com  Fri May 30 13:14:45 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 30 May 2014 17:14:45 +0400
Subject: RFR(S) : 8038756 : new WB API :: get/setVMFlag
In-Reply-To: <538877EE.5080001@oracle.com>
References: <53388795.9070005@oracle.com> <533A892C.2090208@oracle.com>
	<538877EE.5080001@oracle.com>
Message-ID: <53888445.5000801@oracle.com>

Vladimir/Staffan,

Thanks for reviews.

Igor

On 05/30/2014 04:22 PM, Vladimir Ivanov wrote:
> Looks good.
>
> Best regards,
> Vladimir Ivanov
>
> On 4/1/14 1:38 PM, Igor Ignatyev wrote:
>> adding hotspot-dev alias.
>>
>> On 03/31/2014 01:07 AM, Igor Ignatyev wrote:
>>> Hi all,
>>>
>>> Please review the patch which introduces new WhiteBox methods to get and
>>> set VM flags.
>>>
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8038756/webrev.00/
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8038756
>>> testing: jprt

From paul.sandoz at oracle.com  Fri May 30 13:36:19 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 30 May 2014 15:36:19 +0200
Subject: Request for tracking down C1 optimizations: handwritten cartesian
	product similar to flatmap/map performance!
In-Reply-To: <CAHLSyCkz1qjmhfPno=5PhARAWk97L0BvBXUQLZ21tVfXF=91Kg@mail.gmail.com>
References: <CAHLSyCko2tnaRhL8pEp1Oiwy2KM+AnhC1R7HSUAJc1hueSN6LQ@mail.gmail.com>
	<3F26DFBF-0D5C-466C-BF8D-307772516835@oracle.com>
	<CAHLSyCkz1qjmhfPno=5PhARAWk97L0BvBXUQLZ21tVfXF=91Kg@mail.gmail.com>
Message-ID: <06C77BEC-AD0F-4DF6-BB6F-A761D87E5093@oracle.com>


On May 30, 2014, at 2:48 PM, Aggelos Biboudis <biboudis at gmail.com> wrote:

> The quick thing to do, was to produce the log including the generated code:
> 
> http://cgi.di.uoa.gr/~biboudis/hotspot_pid5379.log
> 
> These are what I know:
> 	? The execution happens inside copyInto
> 	? we have three forEachRemaining calls (of, flatMap, map) that are delegated via the accept methods of the wrapped sink.

Just two, there is no loop for the map operation.

In the log search for the compiled method at address 0x00007f1b4909e8d0, then within that search for the instruction imul, then look how the code loops surrounding that instruction.

I can just about fake an understand of x86 machine code :-) AFAICT the capturing instance of LongUnaryOperator passed to the map operation is unboxed.

I have not tried it yet, but JITWatch might help to analyse the logs:

  https://github.com/AdoptOpenJDK/jitwatch

Paul.


> 	? the second lambda which is captured is obtained via a method internalMemberName
> If scalar replacement happens I should expect to see the captured lambda spilled on the stack and accessed accordingly when the execution reaches a request to the reference of the mapper lambda inside flatMap. From what I understand, this should have happened in the accept of flatMap where the inner lambda is linked and more specifically "inside" the mapper.apply of LongPipeline:286, right (in terms of runtime execution)? And even more specifically when accepting the captured lambda (lambda$8 to my understanding). 
> 
> On a side note, I'll produce a debug build of the vm to examine this better. ;-) Thx for the direction.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140530/b36bce9f/signature.asc>

From daniel.daugherty at oracle.com  Fri May 30 14:14:19 2014
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 30 May 2014 08:14:19 -0600
Subject: CodeHeap::expand_by malloc failed
In-Reply-To: <CAHjP37EcnirJ1LoiG0UeLzOTi0uatgb--acFOJowOfGT-FMvdA@mail.gmail.com>
References: <CAHjP37Ea3=tpCUSMnbx4pLrXbWGjXTb19BSD23uJUCgFSwC8ow@mail.gmail.com>
	<E2B85BDE-7F4B-4025-B29E-AFD1AEBCE17D@oracle.com>
	<5387D545.9080404@oracle.com>
	<CAHjP37EcnirJ1LoiG0UeLzOTi0uatgb--acFOJowOfGT-FMvdA@mail.gmail.com>
Message-ID: <5388923B.1000608@oracle.com>

When 'os::commit_memory()' fails, there should be a message like the
following in stderr for the Java process:

Java HotSpot(TM) 64-Bit Server VM warning: INFO: 
os::commit_memory(0xfffffd7fe8c00000, 2097152, 1) failed; 
error='Resource temporarily unavailable' (errno=11)

The address and size should match what you see in the stack trace
which provides confirmation that we have the right mesg, but the
important piece is the errno value...

Dan


On 5/29/14 7:20 PM, Vitaly Davidovich wrote:
> Yes, swap and overcommit are turned off.  But, there's substantial free
> physical memory available and looks like 65kb available to expand the code
> heap contiguoisly.  So I'm a bit puzzled ...
>
> Taking Chris' suggestion and cc'ing hotspot dev ...
>
> Sent from my phone
> On May 29, 2014 8:47 PM, "Vladimir Kozlov" <vladimir.kozlov at oracle.com>
> wrote:
>
>> Could be because there is no swap on this machine:
>>
>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>
>> Vladimir
>>
>> On 5/29/14 5:35 PM, Christian Thalinger wrote:
>>
>>> Although it?s the code cache I assume runtime folk would know more about
>>> this.  Maybe send to hotspot-dev.
>>>
>>> On May 29, 2014, at 9:01 AM, Vitaly Davidovich <vitalyd at gmail.com
>>> <mailto:vitalyd at gmail.com>> wrote:
>>>
>>>   Hi guys,
>>>> Need a bit of help explaining a hotspot malloc failure crash on 7u51.
>>>>   I'm going to paste the relevant snippets from the hs_err log.
>>>>
>>>> #
>>>> # There is insufficient memory for the Java Runtime Environment to
>>>> continue.
>>>> # Native memory allocation (malloc) failed to allocate 65536 bytes for
>>>> committing reserved memory.
>>>> # Possible reasons:
>>>> #   The system is out of physical RAM or swap space
>>>> #   In 32 bit mode, the process size limit was hit
>>>> # Possible solutions:
>>>> #   Reduce memory load on the system
>>>> #   Increase physical memory or swap space
>>>> #   Check if swap backing store is full
>>>> #   Use 64 bit Java on a 64 bit OS
>>>> #   Decrease Java heap size (-Xmx/-Xms)
>>>> #   Decrease number of Java threads
>>>> #   Decrease Java thread stack sizes (-Xss)
>>>> #   Set larger code cache with -XX:ReservedCodeCacheSize=
>>>> # This output file may be truncated or incomplete.
>>>> #
>>>> #  Out of Memory Error (os_linux.cpp:2726), pid=10643, tid=47319048501520
>>>> #
>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build
>>>> 1.7.0_51-b13)
>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode
>>>> linux-amd64 compressed oops)
>>>>
>>>>
>>>> ---------------  T H R E A D  ---------------
>>>>
>>>> Current thread (0x0000000000716800):  JavaThread "C2 CompilerThread0"
>>>> daemon [_thread_in_vm, id=10689,
>>>> stack(0x00002b095303b000,0x00002b095313c000)]
>>>>
>>>> Stack: [0x00002b095303b000,0x00002b095313c000],
>>>>   sp=0x00002b0953138d20,  free space=1015k
>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>> C=native code)
>>>> V  [libjvm.so+0x992f4a]  VMError::report_and_die()+0x2ea
>>>> V  [libjvm.so+0x4931ab]  report_vm_out_of_memory(char const*, int,
>>>> unsigned long, char const*)+0x9b
>>>> V  [libjvm.so+0x81338e]  os::Linux::commit_memory_impl(char*, unsigned
>>>> long, bool)+0xfe
>>>> V  [libjvm.so+0x81383f]  os::Linux::commit_memory_impl(char*, unsigned
>>>> long, unsigned long, bool)+0x4f
>>>> V  [libjvm.so+0x813a2c]  os::pd_commit_memory(char*, unsigned long,
>>>> unsigned long, bool)+0xc
>>>> V  [libjvm.so+0x80daea]  os::commit_memory(char*, unsigned long,
>>>> unsigned long, bool)+0x2a
>>>> V  [libjvm.so+0x98e849]  VirtualSpace::expand_by(unsigned long,
>>>> bool)+0x1c9
>>>> V  [libjvm.so+0x58a62c]  CodeHeap::expand_by(unsigned long)+0x8c
>>>> V  [libjvm.so+0x42111d]  CodeCache::allocate(int)+0x4d
>>>> V  [libjvm.so+0x7e1a39]  nmethod::new_nmethod(methodHandle, int, int,
>>>> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
>>>> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
>>>> ImplicitExceptionTable*, AbstractCompiler*, int)+0x179
>>>> V  [libjvm.so+0x3cfc54]  ciEnv::register_method(ciMethod*, int,
>>>> CodeOffsets*, int, CodeBuffer*, int, OopMapSet*,
>>>> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,
>>>> int, bool, bool)+0x364
>>>> V  [libjvm.so+0x4458fb]  Compile::Compile(ciEnv*, C2Compiler*,
>>>> ciMethod*, int, bool, bool)+0x11cb
>>>> V  [libjvm.so+0x3afa76]  C2Compiler::compile_method(ciEnv*, ciMethod*,
>>>> int)+0x176
>>>> V  [libjvm.so+0x44ba9e]
>>>>   CompileBroker::invoke_compiler_on_method(CompileTask*)+0x33e
>>>> V  [libjvm.so+0x44c87d]  CompileBroker::compiler_thread_loop()+0x43d
>>>> V  [libjvm.so+0x94d5ff]  JavaThread::thread_main_inner()+0xdf
>>>> V  [libjvm.so+0x94d705]  JavaThread::run()+0xf5
>>>> V  [libjvm.so+0x815538]  java_start(Thread*)+0x108
>>>>
>>>> Code Cache  [0x00002b091755c000, 0x00002b091869c000, 0x00002b091a55c000)
>>>>   total_blobs=7033 nmethods=6349 adapters=634 free_code_cache=31715Kb
>>>> largest_free_block=32247296
>>>>
>>>> Memory mappings around the code cache virtual space (bolded line is
>>>> the code cache segment, I believe, based on the Code Cache output above):
>>>>
>>>> *2b091755c000-2b091869c000 rwxp 00000000 00:00 0*
>>>> 2b09186ac000-2b091d66f000 rw-p 00000000 00:00 0
>>>> 2b091d66f000-2b091d670000 ---p 00000000 00:00 0
>>>> 2b091d670000-2b091d770000 rwxp 00000000 00:00 0
>>>> 2b091d770000-2b091d771000 ---p 00000000 00:00 0
>>>> 2b091d771000-2b091d871000 rwxp 00000000 00:00 0
>>>> 2b091d871000-2b091d872000 ---p 00000000 00:00 0
>>>> 2b091d872000-2b091d972000 rwxp 00000000 00:00 0
>>>>
>>>> /proc/meminfo:
>>>> MemTotal:       49521668 kB
>>>> MemFree:         5596796 kB
>>>> Buffers:          294684 kB
>>>> Cached:         34205856 kB
>>>> SwapCached:            0 kB
>>>> Active:         12745128 kB
>>>> Inactive:       28516788 kB
>>>> Active(anon):    9280636 kB
>>>> Inactive(anon):  3090264 kB
>>>> Active(file):    3464492 kB
>>>> Inactive(file): 25426524 kB
>>>> Unevictable:       14420 kB
>>>> Mlocked:           14420 kB
>>>> SwapTotal:             0 kB
>>>> SwapFree:              0 kB
>>>> Dirty:             20392 kB
>>>> Writeback:             0 kB
>>>> AnonPages:       6776540 kB
>>>> Mapped:          6292204 kB
>>>> Shmem:           5604620 kB
>>>> Slab:            1828656 kB
>>>> SReclaimable:    1567928 kB
>>>> SUnreclaim:       260728 kB
>>>> KernelStack:        4648 kB
>>>> PageTables:        58800 kB
>>>> NFS_Unstable:          0 kB
>>>> Bounce:                0 kB
>>>> WritebackTmp:          0 kB
>>>> CommitLimit:    47045584 kB
>>>> Committed_AS:   46046480 kB
>>>> VmallocTotal:   34359738367 kB
>>>> VmallocUsed:      460188 kB
>>>> VmallocChunk:   34333703480 kB
>>>> HugePages_Total:       0
>>>> HugePages_Free:        0
>>>> HugePages_Rsvd:        0
>>>> HugePages_Surp:        0
>>>> Hugepagesize:       2048 kB
>>>> DirectMap4k:        8192 kB
>>>> DirectMap2M:     2080768 kB
>>>> DirectMap1G:    48234496 kB
>>>>
>>>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>>>
>>>> * overcommit is turned off
>>>>
>>>> So the code heap was attempting to expand by 65kb at a fixed address.
>>>>   There appears to be a 65kb mapping available between the end of the
>>>> current code heap mapping (2b091755c000-2b091869c000) and the next one
>>>> (2b09186ac000-2b091d66f000).  There's about 30mb of free space left
>>>> (reserved, but uncommitted I take it) in the virtual space, so it's a
>>>> bit puzzling given there's ample physical mem available.  Only thing I
>>>> can think of is expansion fails because it cannot get contiguous
>>>> space, but then I can't reconcile that with the mem mapping above.
>>>>
>>>> Does anyone have any ideas?
>>>>
>>>> Let me know if you need additional info from the hs_err file.
>>>>
>>>> Thanks
>>>>
>>>>


From vitalyd at gmail.com  Fri May 30 15:04:28 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 30 May 2014 11:04:28 -0400
Subject: CodeHeap::expand_by malloc failed
In-Reply-To: <5388923B.1000608@oracle.com>
References: <CAHjP37Ea3=tpCUSMnbx4pLrXbWGjXTb19BSD23uJUCgFSwC8ow@mail.gmail.com>
	<E2B85BDE-7F4B-4025-B29E-AFD1AEBCE17D@oracle.com>
	<5387D545.9080404@oracle.com>
	<CAHjP37EcnirJ1LoiG0UeLzOTi0uatgb--acFOJowOfGT-FMvdA@mail.gmail.com>
	<5388923B.1000608@oracle.com>
Message-ID: <CAHjP37FL_R0LUF2+TAVGBmSr+CLxZ9qJFo+htDAM38dicjodLQ@mail.gmail.com>

Hi Dan,

Thanks for the pointer.  Here's the relevant line:

Java HotSpot(TM) 64-Bit Server VM warning: INFO:
os::commit_memory(0x00002b091869c000, 65536, 1) failed; error='Cannot
allocate memory' (errno=12)

So it confirms the fixed address at which it's trying to commit and the
65kb size.  The address matches the end of the currently committed code
heap region, but still somewhat puzzling as to why ENOMEM is returned given
the rest of the output in the error report.  Perhaps there was a transient
spike in mem consumption when mmap failed but the condition disappeared
(ie. mem was free'd back to os by another process) by the time the error
reporter pulled mem stats from the kernel?

Thanks


On Fri, May 30, 2014 at 10:14 AM, Daniel D. Daugherty <
daniel.daugherty at oracle.com> wrote:

> When 'os::commit_memory()' fails, there should be a message like the
> following in stderr for the Java process:
>
> Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0xfffffd7fe8c00000,
> 2097152, 1) failed; error='Resource temporarily unavailable' (errno=11)
>
> The address and size should match what you see in the stack trace
> which provides confirmation that we have the right mesg, but the
> important piece is the errno value...
>
> Dan
>
>
>
> On 5/29/14 7:20 PM, Vitaly Davidovich wrote:
>
>> Yes, swap and overcommit are turned off.  But, there's substantial free
>> physical memory available and looks like 65kb available to expand the code
>> heap contiguoisly.  So I'm a bit puzzled ...
>>
>> Taking Chris' suggestion and cc'ing hotspot dev ...
>>
>> Sent from my phone
>> On May 29, 2014 8:47 PM, "Vladimir Kozlov" <vladimir.kozlov at oracle.com>
>> wrote:
>>
>>  Could be because there is no swap on this machine:
>>>
>>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>>
>>> Vladimir
>>>
>>> On 5/29/14 5:35 PM, Christian Thalinger wrote:
>>>
>>>  Although it?s the code cache I assume runtime folk would know more about
>>>> this.  Maybe send to hotspot-dev.
>>>>
>>>> On May 29, 2014, at 9:01 AM, Vitaly Davidovich <vitalyd at gmail.com
>>>> <mailto:vitalyd at gmail.com>> wrote:
>>>>
>>>>   Hi guys,
>>>>
>>>>> Need a bit of help explaining a hotspot malloc failure crash on 7u51.
>>>>>   I'm going to paste the relevant snippets from the hs_err log.
>>>>>
>>>>> #
>>>>> # There is insufficient memory for the Java Runtime Environment to
>>>>> continue.
>>>>> # Native memory allocation (malloc) failed to allocate 65536 bytes for
>>>>> committing reserved memory.
>>>>> # Possible reasons:
>>>>> #   The system is out of physical RAM or swap space
>>>>> #   In 32 bit mode, the process size limit was hit
>>>>> # Possible solutions:
>>>>> #   Reduce memory load on the system
>>>>> #   Increase physical memory or swap space
>>>>> #   Check if swap backing store is full
>>>>> #   Use 64 bit Java on a 64 bit OS
>>>>> #   Decrease Java heap size (-Xmx/-Xms)
>>>>> #   Decrease number of Java threads
>>>>> #   Decrease Java thread stack sizes (-Xss)
>>>>> #   Set larger code cache with -XX:ReservedCodeCacheSize=
>>>>> # This output file may be truncated or incomplete.
>>>>> #
>>>>> #  Out of Memory Error (os_linux.cpp:2726), pid=10643,
>>>>> tid=47319048501520
>>>>> #
>>>>> # JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build
>>>>> 1.7.0_51-b13)
>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode
>>>>> linux-amd64 compressed oops)
>>>>>
>>>>>
>>>>> ---------------  T H R E A D  ---------------
>>>>>
>>>>> Current thread (0x0000000000716800):  JavaThread "C2 CompilerThread0"
>>>>> daemon [_thread_in_vm, id=10689,
>>>>> stack(0x00002b095303b000,0x00002b095313c000)]
>>>>>
>>>>> Stack: [0x00002b095303b000,0x00002b095313c000],
>>>>>   sp=0x00002b0953138d20,  free space=1015k
>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>> C=native code)
>>>>> V  [libjvm.so+0x992f4a]  VMError::report_and_die()+0x2ea
>>>>> V  [libjvm.so+0x4931ab]  report_vm_out_of_memory(char const*, int,
>>>>> unsigned long, char const*)+0x9b
>>>>> V  [libjvm.so+0x81338e]  os::Linux::commit_memory_impl(char*, unsigned
>>>>> long, bool)+0xfe
>>>>> V  [libjvm.so+0x81383f]  os::Linux::commit_memory_impl(char*, unsigned
>>>>> long, unsigned long, bool)+0x4f
>>>>> V  [libjvm.so+0x813a2c]  os::pd_commit_memory(char*, unsigned long,
>>>>> unsigned long, bool)+0xc
>>>>> V  [libjvm.so+0x80daea]  os::commit_memory(char*, unsigned long,
>>>>> unsigned long, bool)+0x2a
>>>>> V  [libjvm.so+0x98e849]  VirtualSpace::expand_by(unsigned long,
>>>>> bool)+0x1c9
>>>>> V  [libjvm.so+0x58a62c]  CodeHeap::expand_by(unsigned long)+0x8c
>>>>> V  [libjvm.so+0x42111d]  CodeCache::allocate(int)+0x4d
>>>>> V  [libjvm.so+0x7e1a39]  nmethod::new_nmethod(methodHandle, int, int,
>>>>> CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,
>>>>> CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,
>>>>> ImplicitExceptionTable*, AbstractCompiler*, int)+0x179
>>>>> V  [libjvm.so+0x3cfc54]  ciEnv::register_method(ciMethod*, int,
>>>>> CodeOffsets*, int, CodeBuffer*, int, OopMapSet*,
>>>>> ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,
>>>>> int, bool, bool)+0x364
>>>>> V  [libjvm.so+0x4458fb]  Compile::Compile(ciEnv*, C2Compiler*,
>>>>> ciMethod*, int, bool, bool)+0x11cb
>>>>> V  [libjvm.so+0x3afa76]  C2Compiler::compile_method(ciEnv*, ciMethod*,
>>>>> int)+0x176
>>>>> V  [libjvm.so+0x44ba9e]
>>>>>   CompileBroker::invoke_compiler_on_method(CompileTask*)+0x33e
>>>>> V  [libjvm.so+0x44c87d]  CompileBroker::compiler_thread_loop()+0x43d
>>>>> V  [libjvm.so+0x94d5ff]  JavaThread::thread_main_inner()+0xdf
>>>>> V  [libjvm.so+0x94d705]  JavaThread::run()+0xf5
>>>>> V  [libjvm.so+0x815538]  java_start(Thread*)+0x108
>>>>>
>>>>> Code Cache  [0x00002b091755c000, 0x00002b091869c000,
>>>>> 0x00002b091a55c000)
>>>>>   total_blobs=7033 nmethods=6349 adapters=634 free_code_cache=31715Kb
>>>>> largest_free_block=32247296
>>>>>
>>>>> Memory mappings around the code cache virtual space (bolded line is
>>>>> the code cache segment, I believe, based on the Code Cache output
>>>>> above):
>>>>>
>>>>> *2b091755c000-2b091869c000 rwxp 00000000 00:00 0*
>>>>> 2b09186ac000-2b091d66f000 rw-p 00000000 00:00 0
>>>>> 2b091d66f000-2b091d670000 ---p 00000000 00:00 0
>>>>> 2b091d670000-2b091d770000 rwxp 00000000 00:00 0
>>>>> 2b091d770000-2b091d771000 ---p 00000000 00:00 0
>>>>> 2b091d771000-2b091d871000 rwxp 00000000 00:00 0
>>>>> 2b091d871000-2b091d872000 ---p 00000000 00:00 0
>>>>> 2b091d872000-2b091d972000 rwxp 00000000 00:00 0
>>>>>
>>>>> /proc/meminfo:
>>>>> MemTotal:       49521668 kB
>>>>> MemFree:         5596796 kB
>>>>> Buffers:          294684 kB
>>>>> Cached:         34205856 kB
>>>>> SwapCached:            0 kB
>>>>> Active:         12745128 kB
>>>>> Inactive:       28516788 kB
>>>>> Active(anon):    9280636 kB
>>>>> Inactive(anon):  3090264 kB
>>>>> Active(file):    3464492 kB
>>>>> Inactive(file): 25426524 kB
>>>>> Unevictable:       14420 kB
>>>>> Mlocked:           14420 kB
>>>>> SwapTotal:             0 kB
>>>>> SwapFree:              0 kB
>>>>> Dirty:             20392 kB
>>>>> Writeback:             0 kB
>>>>> AnonPages:       6776540 kB
>>>>> Mapped:          6292204 kB
>>>>> Shmem:           5604620 kB
>>>>> Slab:            1828656 kB
>>>>> SReclaimable:    1567928 kB
>>>>> SUnreclaim:       260728 kB
>>>>> KernelStack:        4648 kB
>>>>> PageTables:        58800 kB
>>>>> NFS_Unstable:          0 kB
>>>>> Bounce:                0 kB
>>>>> WritebackTmp:          0 kB
>>>>> CommitLimit:    47045584 kB
>>>>> Committed_AS:   46046480 kB
>>>>> VmallocTotal:   34359738367 kB
>>>>> VmallocUsed:      460188 kB
>>>>> VmallocChunk:   34333703480 kB
>>>>> HugePages_Total:       0
>>>>> HugePages_Free:        0
>>>>> HugePages_Rsvd:        0
>>>>> HugePages_Surp:        0
>>>>> Hugepagesize:       2048 kB
>>>>> DirectMap4k:        8192 kB
>>>>> DirectMap2M:     2080768 kB
>>>>> DirectMap1G:    48234496 kB
>>>>>
>>>>> Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)
>>>>>
>>>>> * overcommit is turned off
>>>>>
>>>>> So the code heap was attempting to expand by 65kb at a fixed address.
>>>>>   There appears to be a 65kb mapping available between the end of the
>>>>> current code heap mapping (2b091755c000-2b091869c000) and the next one
>>>>> (2b09186ac000-2b091d66f000).  There's about 30mb of free space left
>>>>> (reserved, but uncommitted I take it) in the virtual space, so it's a
>>>>> bit puzzling given there's ample physical mem available.  Only thing I
>>>>> can think of is expansion fails because it cannot get contiguous
>>>>> space, but then I can't reconcile that with the mem mapping above.
>>>>>
>>>>> Does anyone have any ideas?
>>>>>
>>>>> Let me know if you need additional info from the hs_err file.
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140530/33e3b461/attachment-0001.html>

From vladimir.kozlov at oracle.com  Fri May 30 18:06:45 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 30 May 2014 11:06:45 -0700
Subject: RFR(M): 7033917: closed/compiler/6507107/HeapwalkingTest.java
	sometimes works too long
In-Reply-To: <537F5B70.5040508@oracle.com>
References: <537F5B70.5040508@oracle.com>
Message-ID: <5388C8B5.1050602@oracle.com>

The idead is good but the implementation is way too complex. What you 
want is to exit loops. You don't need special iterators for that.

public class RuntimeEstimator {
     private long end;
     private long last;
     private long worst_iteration;

     public Estimator(long duration) { // duration in seconds
         last = System.currentTimeMillis();
         end = last + duration*1000;
         worst_iteration = 0;
     }

     public boolean timeout() {
         long now = System.currentTimeMillis();
         long iteration = now - last;
         last = now;
         if (iteration >  worst_iteration) {
             worst_iteration = iteration;
         }
         // *2 to be conservative
         return (now + worst_iteration_time*2) > end;
     }
}

In a test's loop you will just check if(est.timeout()) and exit loop.

Vladimir

On 5/23/14 7:30 AM, Morris Meyer wrote:
> Folks,
>
> During the nightly testing we have a class of bugs that crop up with
> compiler flags that change the performance dynamic of the test, such as
> -Xcomp and -XX:+DeoptimizeALot.
>
> Instead of tweaking the test parameters, I have created an Estimator
> class that takes a work List - and creates an Iterator that is looking
> at the expiration clock for the test.  Instead of the test failing out
> for taking too much time for an arbitrary number of iterations, the
> iterator ends, and Estimator will produce a timeout factor suitable for
> the -Dtest.timeout.factor flag.
>
> I've added an EstimatorTest to testlibrary_tests that tests the
> Estimator with three scenarios, too much time, not enough time and just
> enough time.
>
> This test has also been through JPRT.   The changes HeapwalkingTest will
> be sent out for review to the closed list.
>
> Thanks much,
>
>          --morris meyer
>
>
> WEBREV - http://cr.openjdk.java.net/~morris/JDK-7033917-hotspot.01
> JBS - https://bugs.openjdk.java.net/browse/JDK-7033917
>
>

From morris.meyer at oracle.com  Fri May 30 18:10:24 2014
From: morris.meyer at oracle.com (Morris Meyer)
Date: Fri, 30 May 2014 14:10:24 -0400
Subject: RFR(M): 7033917: closed/compiler/6507107/HeapwalkingTest.java
	sometimes works too long
In-Reply-To: <5388C8B5.1050602@oracle.com>
References: <537F5B70.5040508@oracle.com> <5388C8B5.1050602@oracle.com>
Message-ID: <750EE7B9-6D66-4D7D-A224-BD81E42E20A7@oracle.com>

Fair enough.  This is a good simplification.  Thanks Vladimir.

      --mm


> On May 30, 2014, at 2:06 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> The idead is good but the implementation is way too complex. What you want is to exit loops. You don't need special iterators for that.
> 
> public class RuntimeEstimator {
>    private long end;
>    private long last;
>    private long worst_iteration;
> 
>    public Estimator(long duration) { // duration in seconds
>        last = System.currentTimeMillis();
>        end = last + duration*1000;
>        worst_iteration = 0;
>    }
> 
>    public boolean timeout() {
>        long now = System.currentTimeMillis();
>        long iteration = now - last;
>        last = now;
>        if (iteration >  worst_iteration) {
>            worst_iteration = iteration;
>        }
>        // *2 to be conservative
>        return (now + worst_iteration_time*2) > end;
>    }
> }
> 
> In a test's loop you will just check if(est.timeout()) and exit loop.
> 
> Vladimir
> 
>> On 5/23/14 7:30 AM, Morris Meyer wrote:
>> Folks,
>> 
>> During the nightly testing we have a class of bugs that crop up with
>> compiler flags that change the performance dynamic of the test, such as
>> -Xcomp and -XX:+DeoptimizeALot.
>> 
>> Instead of tweaking the test parameters, I have created an Estimator
>> class that takes a work List - and creates an Iterator that is looking
>> at the expiration clock for the test.  Instead of the test failing out
>> for taking too much time for an arbitrary number of iterations, the
>> iterator ends, and Estimator will produce a timeout factor suitable for
>> the -Dtest.timeout.factor flag.
>> 
>> I've added an EstimatorTest to testlibrary_tests that tests the
>> Estimator with three scenarios, too much time, not enough time and just
>> enough time.
>> 
>> This test has also been through JPRT.   The changes HeapwalkingTest will
>> be sent out for review to the closed list.
>> 
>> Thanks much,
>> 
>>         --morris meyer
>> 
>> 
>> WEBREV - http://cr.openjdk.java.net/~morris/JDK-7033917-hotspot.01
>> JBS - https://bugs.openjdk.java.net/browse/JDK-7033917
>> 
>> 

From biboudis at gmail.com  Fri May 30 18:29:17 2014
From: biboudis at gmail.com (Aggelos Biboudis)
Date: Fri, 30 May 2014 21:29:17 +0300
Subject: Request for tracking down C1 optimizations: handwritten cartesian
	product similar to flatmap/map performance!
In-Reply-To: <06C77BEC-AD0F-4DF6-BB6F-A761D87E5093@oracle.com>
References: <CAHLSyCko2tnaRhL8pEp1Oiwy2KM+AnhC1R7HSUAJc1hueSN6LQ@mail.gmail.com>
	<3F26DFBF-0D5C-466C-BF8D-307772516835@oracle.com>
	<CAHLSyCkz1qjmhfPno=5PhARAWk97L0BvBXUQLZ21tVfXF=91Kg@mail.gmail.com>
	<06C77BEC-AD0F-4DF6-BB6F-A761D87E5093@oracle.com>
Message-ID: <CAHLSyC=RKgSoZnSr-Wpbvs=mkLt96XYcDTtmdYE9SGUMNGwPOw@mail.gmail.com>

Experimentally we found that heap allocations do indeed occur. After
increasing the outer stream (of vHigh) and decreasing the vLow (keeping the
total number of iterations to 10000000) we discovered that number of gc
collections increases significantly and the delay is noticeable.

Kind regards,
Aggelos Biboudis.



On Fri, May 30, 2014 at 4:36 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On May 30, 2014, at 2:48 PM, Aggelos Biboudis <biboudis at gmail.com> wrote:
>
> > The quick thing to do, was to produce the log including the generated
> code:
> >
> > http://cgi.di.uoa.gr/~biboudis/hotspot_pid5379.log
> >
> > These are what I know:
> >       ? The execution happens inside copyInto
> >       ? we have three forEachRemaining calls (of, flatMap, map) that are
> delegated via the accept methods of the wrapped sink.
>
> Just two, there is no loop for the map operation.
>
> In the log search for the compiled method at address 0x00007f1b4909e8d0,
> then within that search for the instruction imul, then look how the code
> loops surrounding that instruction.
>
> I can just about fake an understand of x86 machine code :-) AFAICT the
> capturing instance of LongUnaryOperator passed to the map operation is
> unboxed.
>
> I have not tried it yet, but JITWatch might help to analyse the logs:
>
>   https://github.com/AdoptOpenJDK/jitwatch
>
> Paul.
>
>
> >       ? the second lambda which is captured is obtained via a method
> internalMemberName
> > If scalar replacement happens I should expect to see the captured lambda
> spilled on the stack and accessed accordingly when the execution reaches a
> request to the reference of the mapper lambda inside flatMap. From what I
> understand, this should have happened in the accept of flatMap where the
> inner lambda is linked and more specifically "inside" the mapper.apply of
> LongPipeline:286, right (in terms of runtime execution)? And even more
> specifically when accepting the captured lambda (lambda$8 to my
> understanding).
> >
> > On a side note, I'll produce a debug build of the vm to examine this
> better. ;-) Thx for the direction.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140530/1a842016/attachment.html>

From vladimir.kozlov at oracle.com  Fri May 30 19:07:06 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 30 May 2014 12:07:06 -0700
Subject: Request for tracking down C1 optimizations: handwritten cartesian
	product similar to flatmap/map performance!
In-Reply-To: <CAHLSyC=RKgSoZnSr-Wpbvs=mkLt96XYcDTtmdYE9SGUMNGwPOw@mail.gmail.com>
References: <CAHLSyCko2tnaRhL8pEp1Oiwy2KM+AnhC1R7HSUAJc1hueSN6LQ@mail.gmail.com>	<3F26DFBF-0D5C-466C-BF8D-307772516835@oracle.com>	<CAHLSyCkz1qjmhfPno=5PhARAWk97L0BvBXUQLZ21tVfXF=91Kg@mail.gmail.com>	<06C77BEC-AD0F-4DF6-BB6F-A761D87E5093@oracle.com>
	<CAHLSyC=RKgSoZnSr-Wpbvs=mkLt96XYcDTtmdYE9SGUMNGwPOw@mail.gmail.com>
Message-ID: <5388D6DA.2000404@oracle.com>

Hi Aggelos,

Based on your log file I see that you use jdk8 fcs. We switched off 
boxing elimination in jdk8 because of 
https://bugs.openjdk.java.net/browse/JDK-8032566. The bug is fixed in 
8u20 now and the optimization is enabled again. But you can try 
-XX:+EliminateAutoBox flag anyway. May be it can help you but it is not 
guaranteed :).

Regards,
Vladimir

On 5/30/14 11:29 AM, Aggelos Biboudis wrote:
> Experimentally we found that heap allocations do indeed occur. After
> increasing the outer stream (of vHigh) and decreasing the vLow (keeping
> the total number of iterations to 10000000) we discovered that number of
> gc collections increases significantly and the delay is noticeable.
>
> Kind regards,
> Aggelos Biboudis.
>
>
>
> On Fri, May 30, 2014 at 4:36 PM, Paul Sandoz <paul.sandoz at oracle.com
> <mailto:paul.sandoz at oracle.com>> wrote:
>
>
>     On May 30, 2014, at 2:48 PM, Aggelos Biboudis <biboudis at gmail.com
>     <mailto:biboudis at gmail.com>> wrote:
>
>      > The quick thing to do, was to produce the log including the
>     generated code:
>      >
>      > http://cgi.di.uoa.gr/~biboudis/hotspot_pid5379.log
>      >
>      > These are what I know:
>      >       ? The execution happens inside copyInto
>      >       ? we have three forEachRemaining calls (of, flatMap, map)
>     that are delegated via the accept methods of the wrapped sink.
>
>     Just two, there is no loop for the map operation.
>
>     In the log search for the compiled method at address
>     0x00007f1b4909e8d0, then within that search for the instruction
>     imul, then look how the code loops surrounding that instruction.
>
>     I can just about fake an understand of x86 machine code :-) AFAICT
>     the capturing instance of LongUnaryOperator passed to the map
>     operation is unboxed.
>
>     I have not tried it yet, but JITWatch might help to analyse the logs:
>
>     https://github.com/AdoptOpenJDK/jitwatch
>
>     Paul.
>
>
>      >       ? the second lambda which is captured is obtained via a
>     method internalMemberName
>      > If scalar replacement happens I should expect to see the captured
>     lambda spilled on the stack and accessed accordingly when the
>     execution reaches a request to the reference of the mapper lambda
>     inside flatMap. From what I understand, this should have happened in
>     the accept of flatMap where the inner lambda is linked and more
>     specifically "inside" the mapper.apply of LongPipeline:286, right
>     (in terms of runtime execution)? And even more specifically when
>     accepting the captured lambda (lambda$8 to my understanding).
>      >
>      > On a side note, I'll produce a debug build of the vm to examine
>     this better. ;-) Thx for the direction.
>
>

From david.r.chase at oracle.com  Fri May 30 20:36:55 2014
From: david.r.chase at oracle.com (David Chase)
Date: Fri, 30 May 2014 16:36:55 -0400
Subject: RFR(S) : 8029381 : assert(is_method_type()) failed: bad cast
Message-ID: <0BD5E4FD-3DA6-458D-A56A-CB230E6F3F84@oracle.com>


bug: https://bugs.openjdk.java.net/browse/JDK-8029381
webrev: http://cr.openjdk.java.net/~drchase/8029381/webrev.00/

Problem: about once per month this assertion would fail in SQE testing,
usually running one of the streams-related tests with -Xcomp.

  ciMethodType* as_method_type() {
    assert(is_method_type(), "bad cast");
    return (ciMethodType*)this;
  }

The cause was a failure to check "f1" before accessing constant pool
cache entries, and when competing threads raced, junk would be observed.
This would only matter for invokedynamic -- the combo of needing both
invokedynamic and multiple threads racing in the cpcache meant that 
it was observed in the streams tests (even a test hand-crafted to make this
failure occur would only fire about once ever 5000 times, and with -Xcomp that
meant this was painfully slow).

The fix is to insert the check into the access macros themselves
(for both method_type and appendix -- same problem for invokedynamic)
and to remove the now-redundant checks from those places where it had
been done right already.

Testing:

that bug was fixed: distilled the bug trigger out of the streams tests into something that
did nothing by fork-joins into bug triggers.  Then modified hotspot to repeat one side of
the race 1000 times in the event of an invokedynamic.  Observed failures once per 50 runs
in this case, applied fix, observed no failures in 2600 runs.

that no harm was done:
jtreg of hotspot/compiler
jtreg of jdk/{jdk,vm}, no flags and -Xcomp
jprt of hotspot

Question -- should test test case be added?  It practically never fails even when the
bug is unfixed; without tweaking hotspot, it tells you practically nothing at all.  Checking
the fix took all night.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140530/47545df3/signature-0001.asc>

From vladimir.kozlov at oracle.com  Fri May 30 21:34:31 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 30 May 2014 14:34:31 -0700
Subject: RFR(S) : 8029381 : assert(is_method_type()) failed: bad cast
In-Reply-To: <0BD5E4FD-3DA6-458D-A56A-CB230E6F3F84@oracle.com>
References: <0BD5E4FD-3DA6-458D-A56A-CB230E6F3F84@oracle.com>
Message-ID: <5388F967.2070205@oracle.com>

CC to runtime.

Looks good to me. I added 'noreg-hard' (no regression test) label to the 
bug report. You can add more to my comment about not having the test.

Thanks,
Vladimir

On 5/30/14 1:36 PM, David Chase wrote:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8029381
> webrev: http://cr.openjdk.java.net/~drchase/8029381/webrev.00/
>
> Problem: about once per month this assertion would fail in SQE testing,
> usually running one of the streams-related tests with -Xcomp.
>
>    ciMethodType* as_method_type() {
>      assert(is_method_type(), "bad cast");
>      return (ciMethodType*)this;
>    }
>
> The cause was a failure to check "f1" before accessing constant pool
> cache entries, and when competing threads raced, junk would be observed.
> This would only matter for invokedynamic -- the combo of needing both
> invokedynamic and multiple threads racing in the cpcache meant that
> it was observed in the streams tests (even a test hand-crafted to make this
> failure occur would only fire about once ever 5000 times, and with -Xcomp that
> meant this was painfully slow).
>
> The fix is to insert the check into the access macros themselves
> (for both method_type and appendix -- same problem for invokedynamic)
> and to remove the now-redundant checks from those places where it had
> been done right already.
>
> Testing:
>
> that bug was fixed: distilled the bug trigger out of the streams tests into something that
> did nothing by fork-joins into bug triggers.  Then modified hotspot to repeat one side of
> the race 1000 times in the event of an invokedynamic.  Observed failures once per 50 runs
> in this case, applied fix, observed no failures in 2600 runs.
>
> that no harm was done:
> jtreg of hotspot/compiler
> jtreg of jdk/{jdk,vm}, no flags and -Xcomp
> jprt of hotspot
>
> Question -- should test test case be added?  It practically never fails even when the
> bug is unfixed; without tweaking hotspot, it tells you practically nothing at all.  Checking
> the fix took all night.
>

From john.r.rose at oracle.com  Fri May 30 21:50:16 2014
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 30 May 2014 14:50:16 -0700
Subject: RFR(S) : 8029381 : assert(is_method_type()) failed: bad cast
In-Reply-To: <0BD5E4FD-3DA6-458D-A56A-CB230E6F3F84@oracle.com>
References: <0BD5E4FD-3DA6-458D-A56A-CB230E6F3F84@oracle.com>
Message-ID: <57E9DDDF-CFD3-42B9-8765-A4470A384FDD@oracle.com>

Wow, that hurts.  Thanks for tracking and fixing that bug, which I think was mine.

Safe publication is hard enough through a single pointer; it's nearly impossible when two or more words of racy state are involved.

Did you consider guarding more (or all) uses of _flags?  That would be a more disruptive change, of course.

I mean something like (but more complex than):
  intx flags()                     { return is_f1_null() ? 0 : _flags; }

Since CPCE is a highly-wrought racy union (the very model of a modern one) that version of flags wouldn't be appropriate for all typestates.

I agree with Vladimir marking the bug as hard to regression test.

? John

On May 30, 2014, at 1:36 PM, David Chase <david.r.chase at oracle.com> wrote:

> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8029381
> webrev: http://cr.openjdk.java.net/~drchase/8029381/webrev.00/
> 
> Problem: about once per month this assertion would fail in SQE testing,
> usually running one of the streams-related tests with -Xcomp.
> 
>  ciMethodType* as_method_type() {
>    assert(is_method_type(), "bad cast");
>    return (ciMethodType*)this;
>  }
> 
> The cause was a failure to check "f1" before accessing constant pool
> cache entries, and when competing threads raced, junk would be observed.
> This would only matter for invokedynamic -- the combo of needing both
> invokedynamic and multiple threads racing in the cpcache meant that 
> it was observed in the streams tests (even a test hand-crafted to make this
> failure occur would only fire about once ever 5000 times, and with -Xcomp that
> meant this was painfully slow).
> 
> The fix is to insert the check into the access macros themselves
> (for both method_type and appendix -- same problem for invokedynamic)
> and to remove the now-redundant checks from those places where it had
> been done right already.
> 
> Testing:
> 
> that bug was fixed: distilled the bug trigger out of the streams tests into something that
> did nothing by fork-joins into bug triggers.  Then modified hotspot to repeat one side of
> the race 1000 times in the event of an invokedynamic.  Observed failures once per 50 runs
> in this case, applied fix, observed no failures in 2600 runs.
> 
> that no harm was done:
> jtreg of hotspot/compiler
> jtreg of jdk/{jdk,vm}, no flags and -Xcomp
> jprt of hotspot
> 
> Question -- should test test case be added?  It practically never fails even when the
> bug is unfixed; without tweaking hotspot, it tells you practically nothing at all.  Checking
> the fix took all night.


From david.r.chase at oracle.com  Fri May 30 22:14:07 2014
From: david.r.chase at oracle.com (David Chase)
Date: Fri, 30 May 2014 18:14:07 -0400
Subject: RFR(S) : 8029381 : assert(is_method_type()) failed: bad cast
In-Reply-To: <57E9DDDF-CFD3-42B9-8765-A4470A384FDD@oracle.com>
References: <0BD5E4FD-3DA6-458D-A56A-CB230E6F3F84@oracle.com>
	<57E9DDDF-CFD3-42B9-8765-A4470A384FDD@oracle.com>
Message-ID: <14B4F885-6F7C-4F40-8A30-D331C1EEA3E1@oracle.com>


On 2014-05-30, at 5:50 PM, John Rose <john.r.rose at oracle.com> wrote:

> Wow, that hurts.  Thanks for tracking and fixing that bug, which I think was mine.
> 
> Safe publication is hard enough through a single pointer; it's nearly impossible when two or more words of racy state are involved.
> 
> Did you consider guarding more (or all) uses of _flags?  That would be a more disruptive change, of course.
> 
> I mean something like (but more complex than):
>  intx flags()                     { return is_f1_null() ? 0 : _flags; }

Christian and Coleen seemed to think that this race was peculiar to invokedynamic and those two bits.
Perhaps they will have something to say.

David


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140530/f92aeba7/signature.asc>

From christian.thalinger at oracle.com  Fri May 30 23:07:01 2014
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 30 May 2014 16:07:01 -0700
Subject: RFR(S) : 8029381 : assert(is_method_type()) failed: bad cast
In-Reply-To: <14B4F885-6F7C-4F40-8A30-D331C1EEA3E1@oracle.com>
References: <0BD5E4FD-3DA6-458D-A56A-CB230E6F3F84@oracle.com>
	<57E9DDDF-CFD3-42B9-8765-A4470A384FDD@oracle.com>
	<14B4F885-6F7C-4F40-8A30-D331C1EEA3E1@oracle.com>
Message-ID: <812E8E5B-B7A0-4A84-B88C-005CA4E1D989@oracle.com>


On May 30, 2014, at 3:14 PM, David Chase <david.r.chase at oracle.com> wrote:

> 
> On 2014-05-30, at 5:50 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
>> Wow, that hurts.  Thanks for tracking and fixing that bug, which I think was mine.
>> 
>> Safe publication is hard enough through a single pointer; it's nearly impossible when two or more words of racy state are involved.
>> 
>> Did you consider guarding more (or all) uses of _flags?  That would be a more disruptive change, of course.
>> 
>> I mean something like (but more complex than):
>> intx flags()                     { return is_f1_null() ? 0 : _flags; }
> 
> Christian and Coleen seemed to think that this race was peculiar to invokedynamic and those two bits.
> Perhaps they will have something to say.

These are the flags we set in ConstantPoolCacheEntry::set_method_handle_common:

  // Write the flags.
  set_method_flags(as_TosState(adapter->result_type()),
                   ((has_appendix    ? 1 : 0) << has_appendix_shift   ) |
                   ((has_method_type ? 1 : 0) << has_method_type_shift) |
                   (                   1      << is_final_shift       ),
                   adapter->size_of_parameters());

Only appendix and method_type have additional data stored somewhere else (the resolved references array) on which we have to wait to settle before we can read them.  With:

release_set_f1(adapter());

we make sure that?s the case.

I don?t think we can adopt a similar contract for other flags as well.  For example is_final is used for multiple different kinds of entries where either f1 or f2 are set (e.g. invokevirtual vs. invokestatic).  So it would be hard to formulate appropriate guards.

> 
> David
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140530/b60d21d1/attachment.html>

From vladimir.kozlov at oracle.com  Sat May 31 02:30:58 2014
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 30 May 2014 19:30:58 -0700
Subject: Regarding 8033626: C2: Merging exception state: reexecute=true
	vs reexecute=false
In-Reply-To: <5387E641.3090508@oracle.com>
References: <538610B9.6060008@oracle.com>
	<5386609F.7030206@oracle.com>	<5386FA8E.6010901@oracle.com>
	<5387E641.3090508@oracle.com>
Message-ID: <53893EE2.9020208@oracle.com>

I thought about this more. I think we should not generate exceptions in intrinsic when we are going to re-execute the 
method. Interpreter will throw exception if needed and intrinsic has wrong bci anyway (bci of call site and not 
allocation). *We should generate plain "intrinsic" uncommon trap in such case*.
There are GraphKit::is_LibraryCallKit() and is_Parse() methods which allow to check where the request for exception 
generation is coming from.

Regards,
Vladimir

On 5/29/14 7:00 PM, Vladimir Kozlov wrote:
> Now I understand the problem. I think we need to keep separate an exception code which requires re-execution. Currently
> we don't check for should_reexecute() when we merge or search for existing exception code (we only compare type).
>
> Vladimir K.
>
> On 5/29/14 2:14 AM, Vladimir Ivanov wrote:
>> The problem is with exception state of two branches [1].
>> Exception on fast path comes from GraphKit::new_instance during
>> intrinsic construction in LibraryCallKit::inline_native_clone. It is
>> executed under should_reexecute=true. PreserveReexecuteState doesn't
>> touch exception state, so kit.add_exception_states_from(new_jvms) (@
>> callGenerator.cpp:703) tries to accumulate incompatible exceptions from
>> fast & slow paths.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] FAST PATH (intrinsic):
>>
>> JVMS depth=1 loc=5 stk=9 arg=10 mon=14 scalar=14 end=14 mondepth=0 sp=1
>> bci=12 reexecute=false method=virtual jobject
>>
>> Exception state:
>>
>> JVMS depth=1 loc=5 stk=9 arg=9 mon=14 scalar=14 end=14 mondepth=0 sp=0
>> bci=12 reexecute=true method=virtual jobject
>>
>> SLOW PATH
>>
>> JVMS depth=1 loc=5 stk=9 arg=10 mon=14 scalar=14 end=14 mondepth=0 sp=1
>> bci=12 reexecute=false method=virtual jobject
>>
>> Exception state:
>>
>> JVMS depth=1 loc=5 stk=9 arg=9 mon=14 scalar=14 end=14 mondepth=0 sp=0
>> bci=12 reexecute=false method=virtual jobject
>>
>>
>> On 5/29/14 2:18 AM, Vladimir Kozlov wrote:
>>> PredictedIntrinsicGenerator was added to have a general predicate. For
>>> example, AES crypto predicate checks klass of an object pointed by a
>>> field. PredictedCallGenerator checks klass of method's holder only.
>>>
>>> Both cases would have the same problem with reexecute. Using
>>> PredictedIntrinsicGenerator will not help you.
>>>
>>> But you should not have this problem at the merge point, because
>>> reexecute should be reset back after intrinsic is generated:
>>>
>>>    { PreserveReexecuteState preexecs(this);
>>>      jvms()->set_should_reexecute(true);
>>>
>>> It is strange that it is still true after PreserveReexecuteState
>>> destructor.
>>>
>>> Vladimir K
>>>
>>> On 5/28/14 9:37 AM, Vladimir Ivanov wrote:
>>>> Hi,
>>>>
>>>> I'm looking at 8033626 [1]:
>>>> "assert(ex_map->jvms()->same_calls_as(_exceptions->jvms())) failed: all
>>>> collected exceptions must come from the same place".
>>>>
>>>> 8014447 [2] introduced new code shape for virtual intrinsifiable methods
>>>> (Object::hashCode & Object::clone): "invokevirtual Object.clone()" can
>>>> be represented as a PredictedCallGenerator with LibraryIntrinsic on fast
>>>> path and VirtualCallGenerator on slow path.
>>>>
>>>> The problem arises for Object::clone, because for OOM case intrinsified
>>>> version requires reexecution (reexecute=true), but slow path (virtual
>>>> dispatch) doesn't (reexecute=false). Further attempt to finish the
>>>> diamond and merge 2 exception states fires the assertion.
>>>>
>>>> So, I have 2 questions:
>>>>    (1) I don't see any way to merge reexecute=true & reexecute=false
>>>> states, so both branches should have the same reexecute status. Am I
>>>> missing something?
>>>>
>>>>    (2) Does PredictedCallGenerator actually support such shape
>>>> (intrinsic on fast path)? There are 2 call generators:
>>>> PredictedIntrinsicGenerator & PredictedCallGenerator. What's the
>>>> difference?
>>>>
>>>> I see there's a way to customize predicate in
>>>> LibraryCallKit::try_to_predicate() for PredictedIntrinsicGenerator, but
>>>> is it the only reason why PredictedIntrinsicGenerator was introduced?
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8033626
>>>>
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8014447
>>>>      "Object.hashCode intrinsic breaks inline caches"