---------- Forwarded message ---------- From: Weldon Washburn <[EMAIL PROTECTED]> Date: Oct 23, 2006 9:21 AM Subject: Re: [drlvm] A list of drlvm enhancements and limitations To: harmony-dev@incubator.apache.org
All, Just a few minutes ago I sent a mail titled, "[DRLVM][MMTk]" current status and plan". It is way too long and detailed to include in this list of drlvm enhancements. Below is a summary that hopefully is at the appropriate level of detail. Please refer to the above email for more information. Summary of MMTk projects 1) Move the exiting "uswer-level" MMTk port to GCV5 2) Get MMTk SemiSpace, GenMS and CopyMS collector running again. They were broken during migration to latest MMTk source and latest drlvm svn HEAD. 3) Alter DRLVM classloader to force all MMTk classes to be loaded and all methods to be JITed before any java code is executed. Integrate MMTk into an early stage of DRLVM boot. 4) Fix up MMTk/VM porting layer which is located at: drlvm/trunk/vm/MMTki/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk 5) Debug and verify JIT support for MMTk's Uninterruptible class. Run simple multithread app and debug. On 10/17/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Hi Gregory, It is a good idea to put up a live list, thanks. Here are some suggestions on the contents for development items in the VM/JIT. A few may be almost done. We can fine tune...and add other work items as well - MMTk integration: Support for magic classes in Jitrino VM/JIT support for MMTk collectors including RSE and thread suspension ( Weldon, could you please add details?) Thanks > On 10/16/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > Once it's more or less ready let's point to that page from TODO on our > > website > > > > Thanks, > > Mikhail > > > > 2006/10/17, Gregory Shimansky < [EMAIL PROTECTED]>: > > > Hello > > > > > > You know that drlvm was donated by Intel and there was some period of > > time > > > while drlvm was developed internally. We had an internal bugzilla > > server to > > > track the issues. In an effort to move all development to the open > > this > > > internal bugzilla will be closed. > > > > > > The database is quite big and contains a lot of valuable information > > including > > > still open bugs. There are many of them which are not exactly bug > > reports, > > > but requests for enhancements or limitation problems. These small > > issues > > > didn't make it to README because they are mostly minor and low > > priority, but > > > it is better to use information which we have already than rediscover > > these > > > problems again. > > > > > > So not to create a lot of garbage in JIRA like problem requests > > without > > > patches I think it is better to create something like a TODO list for > > drlvm. > > > Not exactly bugs, but more like known limitations list. > > > > > > To give you an example, vm/vmcore/src/init/properties.cpp contains a > > #define > > > MAX_PROP_LINE 5120 which is a maximum property length specified in > > > vm.properties file. I am not even sure if this file still used, > > probably not, > > > but a buffer length limitation is still a bad thing. > > > > > > I think a good place for such list would be on wiki. I am going to > > create a > > > page for it so that everyone who has open bugs inside of Intel could > > add a > > > line or two describing a problem recorded in bugzilla. I have 3 like > > these > > > filed myself including the one I gave as an example. > > > > > > I don't know the number of such bugs overall, maybe it is not so big. > > But > > > before creating JIRAs for them I think it is better to collect a list > > on > > > wiki. What do you think? > > > > > > -- > > > Gregory Shimansky, Intel Middleware Products Division > > > > > >
-- Weldon Washburn Intel Middleware Products Division -- Weldon Washburn Intel Middleware Products Division
