On 10/25/06, Robin Garner <[EMAIL PROTECTED]> 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
