harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [DRLVM][MMTk] current status and plan
Date Mon, 30 Oct 2006 05:08:17 GMT
Weldon Washburn wrote:
> On 10/25/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>> >    follows.  Comments, suggestions are welcome.   It would be much
>> >    appreciated if Steve Blackburn and Robin Garner would reply to the
>> > questions
>> >    below directed to the "MMTk guys".
>> Interleaved below.
>> >          - prepareCollector() method – Its not clear MMTk/DRLVM
>> >          needs to do anything. (MMTk folks please comment on what the
>> > VM is supposed
>> >          to do!)
>> The CollectorContext object is the per-thread context object for each GC
>> thread.  A uniprocessor, single-threaded java program will have one
>> MutatorContext and one CollectorContext.  A uniprocessor multithreaded
>> java program (ie all practical programs on a uniprocessor) will have one
>> CollectorContext and several MutatorContexts.
>> This method is provided so that the VM can do whatever it requires to a
>> collector thread.  If this is nothing (which in drlvm it could well be),
>> this can be a no-op.  Whether that is true or not requires DRLVM 
>> internals
>> knowledge I don't have.
> Can we simply hardwire the number of CollectorContexts to be one?  At a
> later date when this becomes a performance problem on a 4-way SMP, we can
> fix this problem.  What do you think?

For the purposes of initial implementation, sure.  But I'd be inclined 
to debug a parallel collector earlier than that.

>> >          - scheduleFinalizerThread() – do nothing at this stage (It
>> >          will need to be fixed when MMTk/DRLVM is capable of running
>> > workloads that
>> >          need finalizers.)
>> >       - Lock class
>> >          - This looks complete.  (Can MMTk folks take a look and
>> >          confirm?)
>> Lets run through this together on Thursday.
> Well, we did not get to this today in Portland Oregon.  Maybe you can tell
> me what needs to be done over harmony-dev.

I'll have a look in SVN and see what I can do.

>> >          - getObjectType() returns an object of type MMTtype.  
>> Currently
>> >          there is a very simple cache of MMType objects.  We need
>> >          to confirm this approach is functionally correct (MMTk guys,
>> > please
>> >          comment).  Then determine if a simple cache is good enough
>> >          to bring up work loads such as Dacapo and SpecJBB.  A
>> >          design issue that needs to be resolved – what part of the
>> > MMTk heap should
>> >          MMType objects be allocated from?  Maybe ImmortalSpace
>> >          (MMTk guys, is this correct?)
>> When a class is loaded, you should request an MMType from MMTk, then 
>> store
>> it somewhere that it can be returned by this call.  Allocating in
>> ImmortalSpace would be appropriate (or move before each GC using the
>> preCopyGCInstances hook).  JikesRVM does this (immortal allocation) using
>> compile-time allocation policy based on call site (by type) and object
>> type.
> I think this means that MMTk has a requirement on JIT functionality.  That
> is, the JIT must support compile-time allocation policy based on callsite.
> Is this correct?

I don't think it *requires* compile-time allocation policy.  As I say 
above, if you use preCopyGCInstances to move the MMType objects before 
GC, you should be able to allocate them in the general Java heap.  This 
goes for all the MMTk objects (xxContexts, Phases etc).

But VM/Compiler control over allocation policy is certainly very Nice To 
Have for a variety of reasons.

>>    - Project 5
>> >       - Debug and verify JIT support for MMTk's  "Uninterruptible"
>> >       class.  This basically means that the JIT needs to not insert GC
>> >       polling calls when JITing an MMTk class that extends
>> > "Uninterruptible".
>> >       This project depends on VM and JIT support for Back-branch
>> >       polling.  It probably does not need to be fully developed and
>> >       debugged until we try to run multithread java apps.  The reason
>> >       is because it requires two or more running Java thread to create
>> > a condition
>> >       where one thread want to arbitrarily suspend the other java
>> threads
>> > at GC
>> >       safepoints.
>> My feeling is multithreading is so fundamental to Java that this needs to
>> be done pdq.  I'm not sure how the helpers for GCV[45] are going to cope
>> without it.
> Sorry for not being clear.  Yes, multithreading is fundamental to drlvm and
> it works.  I simply want to turn it off for this stage of the MMTk/DRLVM
> port.  Back-branch polling and Uninterruptible have to work for the ongoing
> DRLVM vmmagic vm helper coding that is currently under way.

View raw message