You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Salikh Zakirov (JIRA)" <ji...@apache.org> on 2006/11/30 15:36:21 UTC
[jira] Created: (HARMONY-2384) [drlvm][thread] Make lock
reservation dynamically switchable from the command line
[drlvm][thread] Make lock reservation dynamically switchable from the command line
----------------------------------------------------------------------------------
Key: HARMONY-2384
URL: http://issues.apache.org/jira/browse/HARMONY-2384
Project: Harmony
Issue Type: Improvement
Components: DRLVM
Reporter: Salikh Zakirov
Priority: Minor
This patch is not intended for immediate inclusion.
Rather, it is intended for experimenting with performance benchmarking DRLVM.
The attached patch turns the previously compile-time chosen LOCK_RESERVATION optimization techniques
into command-line swithchable using
-Dthread.lock_reservation=0
The #define LOCK_RESERVATION is still preserved, because its other use is excluding ia32-specific code
from compiling on different platforms. Thus, the above option has meaning only on ia32 platform,
on x86_64 and ipf it will have no effect (and lock reservation will not be turned on, because it is not implemented for those platforms).
The attached patch may also have some negative impact on performance, because it adds runtime checks.
The runtime checks are out of the fast path assembly, but they still are on the slowpath C functions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-2384) [drlvm][thread] Make lock
reservation dynamically switchable from the command line
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2384?page=all ]
Salikh Zakirov updated HARMONY-2384:
------------------------------------
Attachment: configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated2.patch
configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated2.patch:
previous patch didn't work because of botched linking model of objects from thread/src.
It was only yesterday that I noticed that some files are linked to hythr.dll, and others are linked to harmonyvm.dll.
updated2 patch provides a quick fix for the issue.
It shows ~8% difference on a _209_db (enabling lock reservation makes it run faster).
The patch still not intended for inclusion to SVN, but rather for benchmarking experiments.
> [drlvm][thread] Make lock reservation dynamically switchable from the command line
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-2384
> URL: http://issues.apache.org/jira/browse/HARMONY-2384
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Salikh Zakirov
> Priority: Minor
> Attachments: configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated2.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation.patch
>
>
> This patch is not intended for immediate inclusion.
> Rather, it is intended for experimenting with performance benchmarking DRLVM.
> The attached patch turns the previously compile-time chosen LOCK_RESERVATION optimization techniques
> into command-line swithchable using
> -Dthread.lock_reservation=0
> The #define LOCK_RESERVATION is still preserved, because its other use is excluding ia32-specific code
> from compiling on different platforms. Thus, the above option has meaning only on ia32 platform,
> on x86_64 and ipf it will have no effect (and lock reservation will not be turned on, because it is not implemented for those platforms).
> The attached patch may also have some negative impact on performance, because it adds runtime checks.
> The runtime checks are out of the fast path assembly, but they still are on the slowpath C functions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (HARMONY-2384) [drlvm][thread] Make lock reservation
dynamically switchable from the command line
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Salikh Zakirov closed HARMONY-2384.
-----------------------------------
Resolution: Won't Fix
> [drlvm][thread] Make lock reservation dynamically switchable from the command line
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-2384
> URL: https://issues.apache.org/jira/browse/HARMONY-2384
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Salikh Zakirov
> Assigned To: weldon washburn
> Priority: Minor
> Attachments: configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated2.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation.patch
>
>
> This patch is not intended for immediate inclusion.
> Rather, it is intended for experimenting with performance benchmarking DRLVM.
> The attached patch turns the previously compile-time chosen LOCK_RESERVATION optimization techniques
> into command-line swithchable using
> -Dthread.lock_reservation=0
> The #define LOCK_RESERVATION is still preserved, because its other use is excluding ia32-specific code
> from compiling on different platforms. Thus, the above option has meaning only on ia32 platform,
> on x86_64 and ipf it will have no effect (and lock reservation will not be turned on, because it is not implemented for those platforms).
> The attached patch may also have some negative impact on performance, because it adds runtime checks.
> The runtime checks are out of the fast path assembly, but they still are on the slowpath C functions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-2384) [drlvm][thread] Make lock
reservation dynamically switchable from the command line
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2384?page=all ]
Salikh Zakirov updated HARMONY-2384:
------------------------------------
Attachment: configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated.patch
configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated.patch
Fixed: fast path generation functions were missed in the original patch, now the property configures fast paths too.
> [drlvm][thread] Make lock reservation dynamically switchable from the command line
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-2384
> URL: http://issues.apache.org/jira/browse/HARMONY-2384
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Salikh Zakirov
> Priority: Minor
> Attachments: configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation.patch
>
>
> This patch is not intended for immediate inclusion.
> Rather, it is intended for experimenting with performance benchmarking DRLVM.
> The attached patch turns the previously compile-time chosen LOCK_RESERVATION optimization techniques
> into command-line swithchable using
> -Dthread.lock_reservation=0
> The #define LOCK_RESERVATION is still preserved, because its other use is excluding ia32-specific code
> from compiling on different platforms. Thus, the above option has meaning only on ia32 platform,
> on x86_64 and ipf it will have no effect (and lock reservation will not be turned on, because it is not implemented for those platforms).
> The attached patch may also have some negative impact on performance, because it adds runtime checks.
> The runtime checks are out of the fast path assembly, but they still are on the slowpath C functions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-2384) [drlvm][thread] Make lock
reservation dynamically switchable from the command line
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2384?page=comments#action_12455679 ]
Salikh Zakirov commented on HARMONY-2384:
-----------------------------------------
Note on configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated2.patch:
it is for Windows/ia32 only (will not compile on linux)
> [drlvm][thread] Make lock reservation dynamically switchable from the command line
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-2384
> URL: http://issues.apache.org/jira/browse/HARMONY-2384
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Salikh Zakirov
> Priority: Minor
> Attachments: configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated2.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation.patch
>
>
> This patch is not intended for immediate inclusion.
> Rather, it is intended for experimenting with performance benchmarking DRLVM.
> The attached patch turns the previously compile-time chosen LOCK_RESERVATION optimization techniques
> into command-line swithchable using
> -Dthread.lock_reservation=0
> The #define LOCK_RESERVATION is still preserved, because its other use is excluding ia32-specific code
> from compiling on different platforms. Thus, the above option has meaning only on ia32 platform,
> on x86_64 and ipf it will have no effect (and lock reservation will not be turned on, because it is not implemented for those platforms).
> The attached patch may also have some negative impact on performance, because it adds runtime checks.
> The runtime checks are out of the fast path assembly, but they still are on the slowpath C functions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-2384) [drlvm][thread] Make lock
reservation dynamically switchable from the command line
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2384?page=all ]
Salikh Zakirov updated HARMONY-2384:
------------------------------------
Attachment: configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation.patch
configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation.patch
> [drlvm][thread] Make lock reservation dynamically switchable from the command line
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-2384
> URL: http://issues.apache.org/jira/browse/HARMONY-2384
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Salikh Zakirov
> Priority: Minor
> Attachments: configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation.patch
>
>
> This patch is not intended for immediate inclusion.
> Rather, it is intended for experimenting with performance benchmarking DRLVM.
> The attached patch turns the previously compile-time chosen LOCK_RESERVATION optimization techniques
> into command-line swithchable using
> -Dthread.lock_reservation=0
> The #define LOCK_RESERVATION is still preserved, because its other use is excluding ia32-specific code
> from compiling on different platforms. Thus, the above option has meaning only on ia32 platform,
> on x86_64 and ipf it will have no effect (and lock reservation will not be turned on, because it is not implemented for those platforms).
> The attached patch may also have some negative impact on performance, because it adds runtime checks.
> The runtime checks are out of the fast path assembly, but they still are on the slowpath C functions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-2384) [drlvm][thread] Make lock
reservation dynamically switchable from the command line
Posted by "Salikh Zakirov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2384?page=comments#action_12460512 ]
Salikh Zakirov commented on HARMONY-2384:
-----------------------------------------
Yes, please close it as you like.
> [drlvm][thread] Make lock reservation dynamically switchable from the command line
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-2384
> URL: http://issues.apache.org/jira/browse/HARMONY-2384
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Salikh Zakirov
> Assigned To: weldon washburn
> Priority: Minor
> Attachments: configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated2.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation.patch
>
>
> This patch is not intended for immediate inclusion.
> Rather, it is intended for experimenting with performance benchmarking DRLVM.
> The attached patch turns the previously compile-time chosen LOCK_RESERVATION optimization techniques
> into command-line swithchable using
> -Dthread.lock_reservation=0
> The #define LOCK_RESERVATION is still preserved, because its other use is excluding ia32-specific code
> from compiling on different platforms. Thus, the above option has meaning only on ia32 platform,
> on x86_64 and ipf it will have no effect (and lock reservation will not be turned on, because it is not implemented for those platforms).
> The attached patch may also have some negative impact on performance, because it adds runtime checks.
> The runtime checks are out of the fast path assembly, but they still are on the slowpath C functions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (HARMONY-2384) [drlvm][thread] Make lock
reservation dynamically switchable from the command line
Posted by "weldon washburn (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2384?page=all ]
weldon washburn reassigned HARMONY-2384:
----------------------------------------
Assignee: weldon washburn
> [drlvm][thread] Make lock reservation dynamically switchable from the command line
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-2384
> URL: http://issues.apache.org/jira/browse/HARMONY-2384
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Salikh Zakirov
> Assigned To: weldon washburn
> Priority: Minor
> Attachments: configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated2.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation.patch
>
>
> This patch is not intended for immediate inclusion.
> Rather, it is intended for experimenting with performance benchmarking DRLVM.
> The attached patch turns the previously compile-time chosen LOCK_RESERVATION optimization techniques
> into command-line swithchable using
> -Dthread.lock_reservation=0
> The #define LOCK_RESERVATION is still preserved, because its other use is excluding ia32-specific code
> from compiling on different platforms. Thus, the above option has meaning only on ia32 platform,
> on x86_64 and ipf it will have no effect (and lock reservation will not be turned on, because it is not implemented for those platforms).
> The attached patch may also have some negative impact on performance, because it adds runtime checks.
> The runtime checks are out of the fast path assembly, but they still are on the slowpath C functions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-2384) [drlvm][thread] Make lock
reservation dynamically switchable from the command line
Posted by "weldon washburn (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-2384?page=comments#action_12457569 ]
weldon washburn commented on HARMONY-2384:
------------------------------------------
Salikh,
Since the intention is to never commit this patch, can it be "closed" with a disposition of something like "later" or "won't fix"?
> [drlvm][thread] Make lock reservation dynamically switchable from the command line
> ----------------------------------------------------------------------------------
>
> Key: HARMONY-2384
> URL: http://issues.apache.org/jira/browse/HARMONY-2384
> Project: Harmony
> Issue Type: Improvement
> Components: DRLVM
> Reporter: Salikh Zakirov
> Assigned To: weldon washburn
> Priority: Minor
> Attachments: configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation-updated2.patch, configure-TM_LOCK_RESERVATION-from-Dthread.lock_reservation.patch
>
>
> This patch is not intended for immediate inclusion.
> Rather, it is intended for experimenting with performance benchmarking DRLVM.
> The attached patch turns the previously compile-time chosen LOCK_RESERVATION optimization techniques
> into command-line swithchable using
> -Dthread.lock_reservation=0
> The #define LOCK_RESERVATION is still preserved, because its other use is excluding ia32-specific code
> from compiling on different platforms. Thus, the above option has meaning only on ia32 platform,
> on x86_64 and ipf it will have no effect (and lock reservation will not be turned on, because it is not implemented for those platforms).
> The attached patch may also have some negative impact on performance, because it adds runtime checks.
> The runtime checks are out of the fast path assembly, but they still are on the slowpath C functions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira