harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM][MMTk] current status and plan
Date Fri, 27 Oct 2006 04:22:27 GMT
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?

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

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

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

Weldon Washburn
Intel Enterprise Solutions Software Division
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message