harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Salikh Zakirov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-2384) [drlvm][thread] Make lock reservation dynamically switchable from the command line
Date Tue, 05 Dec 2006 16:06:23 GMT
    [ 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
> into command-line swithchable using
>      -Dthread.lock_reservation=0
> The #define LOCK_RESERVATION is still preserved, because its other use is excluding ia32-specific
> from compiling on different platforms. Thus, the above option has meaning only on ia32
> 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


View raw message