« Return to Thread: [jira] Created: (RVM-791) Clean up and modularize locking

[jira] Commented: (RVM-791) Clean up and modularize locking

by JIRA jira@codehaus.org :: Rate this Message:

Reply to Author | View in Thread


    [ http://jira.codehaus.org/browse/RVM-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165759#action_165759 ]

Ian Rogers commented on RVM-791:
--------------------------------

I agree the changes are largely orthogonal. There are possible interactions:

1) we tend to define constants (which to me look like C style .h file - yuck) and then these permeate the code base, the new model requires the implementation to call back into the object model so that the layout of objects is abstracted

2) the compilers currently have explicit information about how to optimize for thin locks (ie inline particular methods). We need to abstract this in much the same way as MMTk has abstracted barriers.

My plan had been that whenever the compiler needed to interact with an object it did this via the object model. For monitors there was a runtime entrypoint that bounced into the object model which via its header would then interact with the scheduler.

The attached code is a WIP and I would be happy for it to get merged with this work and forward progress made. I'm currently trying to fix Harmony (with a large rewrite of most of the syscalls).

The work needed on this code is:
1) bring it up-to-date with trunk
2) remove all uses of the old object model to move it to the new object model
3) test the abstraction out - hopefully with a bidirectional model, but there are also issues with squeezing the header size on 64bit platforms
4) handle the misc header in some kind of clean and elegant way (it's a frequent issue for users)

I also think that the object model should probably be abstracting static field accesses. This could allow us to have multiple static field implementations, such as the JTOC vs. hanging statics off of RVMClass vs. hanging statics of CodeArray.

There's lots of work to do, I just really wanted you to have a heads up on what my thinking is. I've tried to capture this in the past through JIRA entries.

> Clean up and modularize locking
> -------------------------------
>
>                 Key: RVM-791
>                 URL: http://jira.codehaus.org/browse/RVM-791
>             Project: RVM
>          Issue Type: Improvement
>          Components: Runtime: Threads and Concurrency
>            Reporter: Filip Pizlo
>            Assignee: Filip Pizlo
>         Attachments: NewObjectModel.tar.gz
>
>
> Currently, Jikes RVM only allows for one style of locking.  We'd like to be able to support multiple styles (eventually, it would be nice to have biased locking).  As well, the locking code crosscuts more files than it needs to, largely for historical, rather than functional, reasons.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Jikesrvm-issues mailing list
Jikesrvm-issues@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-issues

 « Return to Thread: [jira] Created: (RVM-791) Clean up and modularize locking