hotspot-dev Digest, Vol 117, Issue 7
Asim Aslam
asim2025 at yahoo.com
Tue Jan 10 01:07:06 UTC 2017
> On Jan 9, 2017, at 8:03 PM, hotspot-dev-request at openjdk.java.net wrote:
>
> Send hotspot-dev mailing list submissions to
> hotspot-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-dev
> or, via email, send a message with subject or body 'help' to
> hotspot-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
> hotspot-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hotspot-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: CFV: New hotspot Group Member: Aleksey Shipilev
> (Vladimir Kozlov)
> 2. Re: CFV: New hotspot Group Member: Aleksey Shipilev
> (Mikael Gerdin)
> 3. Re: CFV: New hotspot Group Member: Aleksey Shipilev
> (Tobias Hartmann)
> 4. Re: CFV: New hotspot Group Member: Aleksey Shipilev (Zolt?n Maj?)
> 5. Re: Hotspot for BSD / opinion request (Daniel D. Daugherty)
> 6. Re: Hotspot for BSD / opinion request (David CARLIER)
> 7. Re: CFV: New hotspot Group Member: Aleksey Shipilev
> (Daniel D. Daugherty)
> 8. Re: RFR(S): 8171266: PPC64: Add support to
> -XX:RTMSpinLoopCount=0 (Vladimir Kozlov)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 9 Jan 2017 01:34:05 -0800
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> To: hotspot-dev at openjdk.java.net
> Subject: Re: CFV: New hotspot Group Member: Aleksey Shipilev
> Message-ID: <5939c52a-842c-6722-1afd-3ebc4b430bf2 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Vote: yes
>
>> On 1/6/17 8:45 AM, Roland Westrelin wrote:
>>
>> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
>> Membership in the hotspot Group.
>>
>> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
>> has been working on Hotspot for 3 years and contributed more than 50
>> changes.
>>
>> Votes are due by Thu, January 20, 2017.
>>
>> Only current Members of the hotspot Group [1] are eligible to vote on
>> this nomination. Votes must be cast in the open by replying to this
>> mailing list
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Roland.
>>
>> [1] http://openjdk.java.net/census#hotspot
>> [2] http://openjdk.java.net/groups/#member-vote
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 9 Jan 2017 10:39:14 +0100
> From: Mikael Gerdin <mikael.gerdin at oracle.com>
> To: hotspot-dev at openjdk.java.net
> Subject: Re: CFV: New hotspot Group Member: Aleksey Shipilev
> Message-ID: <edd67981-84b1-99df-1b4b-58d8c35082f7 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Vote: yes
>
> /Mikael
>
>> On 2017-01-06 17:45, Roland Westrelin wrote:
>>
>> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
>> Membership in the hotspot Group.
>>
>> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
>> has been working on Hotspot for 3 years and contributed more than 50
>> changes.
>>
>> Votes are due by Thu, January 20, 2017.
>>
>> Only current Members of the hotspot Group [1] are eligible to vote on
>> this nomination. Votes must be cast in the open by replying to this
>> mailing list
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Roland.
>>
>> [1] http://openjdk.java.net/census#hotspot
>> [2] http://openjdk.java.net/groups/#member-vote
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 9 Jan 2017 11:11:51 +0100
> From: Tobias Hartmann <tobias.hartmann at oracle.com>
> To: Roland Westrelin <rwestrel at redhat.com>,
> hotspot-dev at openjdk.java.net
> Subject: Re: CFV: New hotspot Group Member: Aleksey Shipilev
> Message-ID: <587361E7.3040702 at oracle.com>
> Content-Type: text/plain; charset=windows-1252
>
> Vote: yes
>
>> On 06.01.2017 17:45, Roland Westrelin wrote:
>>
>> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
>> Membership in the hotspot Group.
>>
>> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
>> has been working on Hotspot for 3 years and contributed more than 50
>> changes.
>>
>> Votes are due by Thu, January 20, 2017.
>>
>> Only current Members of the hotspot Group [1] are eligible to vote on
>> this nomination. Votes must be cast in the open by replying to this
>> mailing list
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Roland.
>>
>> [1] http://openjdk.java.net/census#hotspot
>> [2] http://openjdk.java.net/groups/#member-vote
>>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 9 Jan 2017 15:22:05 +0100
> From: Zolt?n Maj? <zoltan.majo at oracle.com>
> To: Roland Westrelin <rwestrel at redhat.com>,
> hotspot-dev at openjdk.java.net
> Subject: Re: CFV: New hotspot Group Member: Aleksey Shipilev
> Message-ID: <0ffe7b2c-da42-ad51-4639-e26b748b8f8f at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Vote: yes.
>
> Best regards,
>
>
> Zoltan
>
>> On 01/06/2017 05:45 PM, Roland Westrelin wrote:
>> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
>> Membership in the hotspot Group.
>>
>> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
>> has been working on Hotspot for 3 years and contributed more than 50
>> changes.
>>
>> Votes are due by Thu, January 20, 2017.
>>
>> Only current Members of the hotspot Group [1] are eligible to vote on
>> this nomination. Votes must be cast in the open by replying to this
>> mailing list
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Roland.
>>
>> [1] http://openjdk.java.net/census#hotspot
>> [2] http://openjdk.java.net/groups/#member-vote
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 9 Jan 2017 09:48:21 -0700
> From: "Daniel D. Daugherty" <daniel.daugherty at oracle.com>
> To: David CARLIER <devnexen at gmail.com>, David Holmes
> <david.holmes at oracle.com>
> Cc: "ppc-aix-port-dev at openjdk.java.net"
> <ppc-aix-port-dev at openjdk.java.net>, hotspot-dev Source Developers
> <hotspot-dev at openjdk.java.net>
> Subject: Re: Hotspot for BSD / opinion request
> Message-ID: <3c580abc-9333-8803-abc1-1b0863123060 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> David C.,
>
> If you sent the patch as an attachment, then you should be advised that
> the OpenJDK email servers strip attachments. If the patch is relatively
> small, then you can send it in-line...
>
> Dan
>
>
>> On 1/6/17 3:23 PM, David CARLIER wrote:
>> Thanks, here a patch proposal. Kindest regards.
>>
>>> On 24 December 2016 at 02:16, David Holmes <david.holmes at oracle.com> wrote:
>>> If there is a platform, we support, where the default settings are
>>> inappropriate then setting them explicitly would be the right thing to do.
>>>
>>> David
>>>
>>>
>>>> On 24/12/2016 10:23 AM, Vladimir Kozlov wrote:
>>>> Hi,
>>>>
>>>> Forwarding to mailing lists since I can't answer.
>>>> May be someone can answer your question on these lists.
>>>>
>>>> Regards,
>>>> Vladimir
>>>>
>>>>> On 12/23/16 2:17 AM, David CARLIER wrote:
>>>>> Hi,
>>>>>
>>>>> this is my first mail to the maiing list, I have difficulties to push
>>>>> messages to any mailing lists, but as BSD user/dev I was
>>>>> looking at code's part like this one
>>>>>
>>>>>
>>>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp
>>>>>
>>>>>
>>>>> I was wondering if it would be better to explicitally set the attr
>>>>> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux
>>>>> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default).
>>>>>
>>>>> What do you think ?
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Kindest regards.
>>>>>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 9 Jan 2017 17:37:47 +0000
> From: David CARLIER <devnexen at gmail.com>
> To: daniel.daugherty at oracle.com
> Cc: "ppc-aix-port-dev at openjdk.java.net"
> <ppc-aix-port-dev at openjdk.java.net>, hotspot-dev Source Developers
> <hotspot-dev at openjdk.java.net>
> Subject: Re: Hotspot for BSD / opinion request
> Message-ID:
> <CA+XhMqz1L2NXCsYikwt4d89i9zLDBJDNW2O6BW5339SJpSHVQQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi sure thing
>
> diff --git a/src/os/bsd/vm/os_bsd.hpp b/src/os/bsd/vm/os_bsd.hpp
> --- a/src/os/bsd/vm/os_bsd.hpp
> +++ b/src/os/bsd/vm/os_bsd.hpp
> @@ -175,6 +175,7 @@
> volatile int _Event;
> volatile int _nParked;
> pthread_mutex_t _mutex[1];
> + pthread_mutexattr_t _attr[1];
> pthread_cond_t _cond[1];
> double PostPad[2];
> Thread * _Assoc;
> @@ -187,7 +188,11 @@
> int status;
> status = pthread_cond_init(_cond, NULL);
> assert_status(status == 0, status, "cond_init");
> - status = pthread_mutex_init(_mutex, NULL);
> + status = pthread_mutexattr_init(_attr);
> + assert_status(status == 0, status, "attr_init");
> + status = pthread_mutexattr_settype(_attr, PTHREAD_MUTEX_NORMAL);
> + assert_status(status == 0, status, "attr_settype");
> + status = pthread_mutex_init(_mutex, _attr);
> assert_status(status == 0, status, "mutex_init");
> _Event = 0;
> _nParked = 0;
> @@ -206,6 +211,7 @@
> class PlatformParker : public CHeapObj<mtInternal> {
> protected:
> pthread_mutex_t _mutex[1];
> + pthread_mutexattr_t _attr[1];
> pthread_cond_t _cond[1];
>
> public: // TODO-FIXME: make dtor private
> @@ -216,7 +222,11 @@
> int status;
> status = pthread_cond_init(_cond, NULL);
> assert_status(status == 0, status, "cond_init");
> - status = pthread_mutex_init(_mutex, NULL);
> + status = pthread_mutexattr_init(_attr);
> + assert_status(status == 0, status, "attr_init");
> + status = pthread_mutexattr_settype(_attr, PTHREAD_MUTEX_NORMAL);
> + assert_status(status == 0, status, "attr_settype");
> + status = pthread_mutex_init(_mutex, _attr);
> assert_status(status == 0, status, "mutex_init");
> }
> };
>
>
>
> Kind regards.
>
> Thanks.
>
> On 9 January 2017 at 16:48, Daniel D. Daugherty
> <daniel.daugherty at oracle.com> wrote:
>> David C.,
>>
>> If you sent the patch as an attachment, then you should be advised that
>> the OpenJDK email servers strip attachments. If the patch is relatively
>> small, then you can send it in-line...
>>
>> Dan
>>
>>
>>
>>> On 1/6/17 3:23 PM, David CARLIER wrote:
>>>
>>> Thanks, here a patch proposal. Kindest regards.
>>>
>>> On 24 December 2016 at 02:16, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>>
>>>> If there is a platform, we support, where the default settings are
>>>> inappropriate then setting them explicitly would be the right thing to
>>>> do.
>>>>
>>>> David
>>>>
>>>>
>>>>> On 24/12/2016 10:23 AM, Vladimir Kozlov wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Forwarding to mailing lists since I can't answer.
>>>>> May be someone can answer your question on these lists.
>>>>>
>>>>> Regards,
>>>>> Vladimir
>>>>>
>>>>>> On 12/23/16 2:17 AM, David CARLIER wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> this is my first mail to the maiing list, I have difficulties to push
>>>>>> messages to any mailing lists, but as BSD user/dev I was
>>>>>> looking at code's part like this one
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp
>>>>>>
>>>>>>
>>>>>> I was wondering if it would be better to explicitally set the attr
>>>>>> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux
>>>>>> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default).
>>>>>>
>>>>>> What do you think ?
>>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Kindest regards.
>>>>>>
>>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 9 Jan 2017 11:14:19 -0700
> From: "Daniel D. Daugherty" <daniel.daugherty at oracle.com>
> To: hotspot-dev at openjdk.java.net
> Subject: Re: CFV: New hotspot Group Member: Aleksey Shipilev
> Message-ID: <9cc7da90-ee6f-44d4-6976-4dfee73f4001 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Vote: yes
>
> Dan
>
>
>> On 1/6/17 9:45 AM, Roland Westrelin wrote:
>> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
>> Membership in the hotspot Group.
>>
>> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
>> has been working on Hotspot for 3 years and contributed more than 50
>> changes.
>>
>> Votes are due by Thu, January 20, 2017.
>>
>> Only current Members of the hotspot Group [1] are eligible to vote on
>> this nomination. Votes must be cast in the open by replying to this
>> mailing list
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Roland.
>>
>> [1] http://openjdk.java.net/census#hotspot
>> [2] http://openjdk.java.net/groups/#member-vote
>>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 9 Jan 2017 17:02:58 -0800
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> To: Gustavo Romero <gromero at linux.vnet.ibm.com>, Volker Simonis
> <volker.simonis at gmail.com>
> Cc: "ppc-aix-port-dev at openjdk.java.net"
> <ppc-aix-port-dev at openjdk.java.net>, "hotspot-dev at openjdk.java.net"
> <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR(S): 8171266: PPC64: Add support to
> -XX:RTMSpinLoopCount=0
> Message-ID: <5df0a239-d242-5853-0f47-2fd2e6d8afcb at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I looked on linux test machines we run and they don't RTM :(
>
> Or few machines with RTM are not used to run these particular tests.
>
> Vladimir
>
>> On 1/5/17 12:18 PM, Gustavo Romero wrote:
>> Hi Volker,
>>
>> Please see my comments inline.
>>
>>> On 05-01-2017 11:18, Volker Simonis wrote:
>>> Hi Gustavo,
>>>
>>> I finally got a Power machine which supports RTM.
>>
>> Good :)
>>
>>
>>> So before pushing this change, I thought I run the RTM jtreg tests.
>>>
>>> Obviously your change improves the situation by preventing crashes
>>> because of RTMSpinLoopCount=0. But I still get 10 failures when
>>> running the RTM tests (test/compiler/rtm) on linux/ppc64:
>>
>> Yes, before my change TestRTMSpinLoopCount.java was just crashing the JVM. But
>> after that the test is not passing yet. It looks like it is expecting fewer
>> abortions and I'm wondering if it's because on Power the transaction is aborted
>> if a signal is caught in the middle (the JVM uses signal quite frequently...),
>> thus an intrinsic property of the JVM on Power. I'll continue the investigation.
>>
>>
>>>
>>> compiler/rtm/locking/TestRTMAbortRatio.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Expected to get exit
>>> value of [0]
>>> compiler/rtm/locking/TestRTMAbortThreshold.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Expected that method with
>>> rtm lock elision was deoptimized after 1 lock attempts: expected 10000
>>> to equal 1
>>> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Two uncommon traps with
>>> reason rtm_state_change should be fired.: expected 0 to equal 2
>>> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Expected to get only one
>>> deoptimization due to rtm state change: expected 0 to equal 1
>>> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Expected to get only one
>>> deoptimization due to rtm state change: expected 0 to equal 1
>>> compiler/rtm/locking/TestRTMLockingCalculationDelay.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: At least one
>>> deoptimization due to rtm_state_chage is expected: expected 0 > 0
>>> compiler/rtm/locking/TestRTMLockingThreshold.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: VM output should contain
>>> two RTM locking statistics entries.: expected 1 to equal 2
>>> compiler/rtm/locking/TestRTMRetryCount.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: It is expected to get 2
>>> aborts: expected 3 to equal 2
>>> compiler/rtm/locking/TestRTMSpinLoopCount.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Total aborts count (2001)
>>> should be less or equal to 1001: expected that 2001 <= 1001
>>> compiler/rtm/locking/TestUseRTMXendForLockBusy.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: VM output should contain
>>> exactly one rtm locking statistics entry for method
>>> compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
>>> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: RTM locking statistics
>>> should contain non zero total aborts count: expected 0 > 0
>>>
>>> On the other hand, the situation on linux/x86_64 seems similar (with
>>> 7-9 failures depending on the run):
>>>
>>> compiler/rtm/locking/TestRTMAbortThreshold.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: Expected that
>>> method with rtm lock elision was deoptimized after 1 lock attempts:
>>> expected 10000 to equal 1
>>> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: Two uncommon traps
>>> with reason rtm_state_change should be fired.: expected 0 to equal 2
>>> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: Expected to get
>>> only one deoptimization due to rtm state change: expected 0 to equal 1
>>> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: After
>>> LockThreshold was reached, method should be recompiled with rtm lock
>>> eliding.: expected null to not equal null
>>> compiler/rtm/locking/TestRTMLockingCalculationDelay.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: At least one
>>> deoptimization due to rtm_state_chage is expected: expected 0 > 0
>>> compiler/rtm/locking/TestRTMLockingThreshold.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: VM output should
>>> contain two RTM locking statistics entries.: expected 1 to equal 2
>>> compiler/rtm/locking/TestRTMTotalCountIncrRate.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: VM output should
>>> contain exactly one RTM locking statistics entry for method
>>> compiler.rtm.locking.TestRTMTotalCountIncrRate$Test::lock: expected 0
>>> to equal 1
>>> compiler/rtm/locking/TestUseRTMXendForLockBusy.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: VM output should
>>> contain exactly one rtm locking statistics entry for method
>>> compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
>>> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: RTM locking
>>> statistics should contain non zero total aborts count: expected 0 > 0
>>>
>>> Are these the same results you are seeing as well?
>>
>> I don't have access to a x64 machine w/ RTM at the moment, but IIRC some tests
>> are failing as well, but fewer in comparison to Power. Much unfortunately I
>> don't know when I'll be able to have a x64 machine available again...
>>
>> I've got the following tests status on a POWER8 machine:
>>
>> FAILED: compiler/rtm/locking/TestRTMAbortThreshold.java
>> FAILED: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
>> FAILED: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
>> FAILED: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
>> FAILED: compiler/rtm/locking/TestRTMLockingCalculationDelay.java
>> FAILED: compiler/rtm/locking/TestRTMLockingThreshold.java
>> FAILED: compiler/rtm/locking/TestRTMRetryCount.java
>> FAILED: compiler/rtm/locking/TestRTMSpinLoopCount.java
>> FAILED: compiler/rtm/locking/TestUseRTMXendForLockBusy.java
>> FAILED: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
>> Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java
>> Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnUnsupportedConfig.java
>> Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java
>> Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java
>> Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java
>> Passed: compiler/rtm/cli/TestRTMRetryCountOption.java
>> Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java
>> Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnUnsupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java
>> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedVM.java
>> Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
>> Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java
>> Passed: compiler/rtm/locking/TestRTMAbortRatio.java
>> Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java
>> Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java
>> Passed: compiler/rtm/locking/TestUseRTMDeopt.java
>> Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java
>> Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java
>> Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java
>> Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java
>> Test results: passed: 28; failed: 10
>>
>> Hence similar to what you've reported, except for TestRTMAbortRatio.java
>> which passed [1], although I would expect more aborts than what was
>> reported.
>>
>>
>>> The JDK 9 Early Access Build Test Results site at
>>> http://download.java.net/openjdk/testresults/9/testresults.html
>>> reports these tests as passed, but I think that may be because they
>>> run on hardware which doesn't support RTM?
>>
>> Exactly. I discussed that briefly with David here [2] when fixing [3]
>> and I guess that's the reason for the regression 8171236 [4] not being
>> detected firstly at the Oracle side.
>>
>>
>> Regards,
>> Gustavo
>>
>> [1] http://paste.fedoraproject.org/520455/83645916/raw/
>> [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024361.html
>> [3] https://bugs.openjdk.java.net/browse/JDK-8164987
>> [4] https://bugs.openjdk.java.net/browse/JDK-8171236
>>
>>
>>> @Vladimir, David: do you regularly run the RTM tests on linux/x86_64
>>> and do they really all pass in your environment? (I've tested with
>>> Linux 3.10 on a "Intel(R) Xeon(R) CPU E7-4820 v3" and with Windows 7
>>> on a "Intel(R) Core(TM) i5-4300U" which according to /proc/cpuinfo and
>>> coreinfo.exe both support RTM).
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>> On Thu, Jan 5, 2017 at 3:03 AM, Gustavo Romero
>>> <gromero at linux.vnet.ibm.com> wrote:
>>>> Hi
>>>>
>>>>> On 03-01-2017 16:08, Volker Simonis wrote:
>>>>> Hi David,
>>>>>
>>>>> thanks for looking at this change.
>>>>> As this is ppc64-only, I'll sponsor it.
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>
>>>> David, thanks for reviewing the change.
>>>>
>>>> Volker, thanks for sponsoring it.
>>>>
>>>> Vladimir, thanks for setting the proper priority and fix version tag.
>>>>
>>>>
>>>> Regards,
>>>> Gustavo
>>>>
>>>>>> On Tue, Jan 3, 2017 at 12:53 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>> Seems fine.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> On 30/12/2016 11:59 PM, Gustavo Romero wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but
>>>>>>> since
>>>>>>> I understand that a formal review has to be submitted to the hs ML I
>>>>>>> resent it.
>>>>>>>
>>>>>>> Is any thing missing on my side?
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Gustavo
>>>>>>>
>>>>>>> [1]
>>>>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html
>>>>>>>
>>>>>>>> On 15-12-2016 19:03, Gustavo Romero wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Could the following change be reviewed please?
>>>>>>>>
>>>>>>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/
>>>>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Gustavo
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> End of hotspot-dev Digest, Vol 117, Issue 7
> *******************************************
More information about the hotspot-dev
mailing list