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] Updated: (HARMONY-2384) [drlvm][thread] Make lock reservation dynamically switchable from the command line
Date Tue, 05 Dec 2006 11:36:22 GMT
     [ 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


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
> 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