Re: Parallel GC for parrot - does it make sense?
Thanks, Will! I succeeded to merge Harmony tree into my local copy: $ svn propget svn:externals src/gc gen http://svn.apache.org/repos/asf/harmony/enhanced/drlvm/trunk/vm/gc_gen/src Then I fixed Manifest.pm to process external entries correctly and started to understand that MANIFEST is used mainly for bundling of the product. It seems to me that it is not used for Makefile generation. Is it true that config/gen/makefiles/root.in is hand-written? Thanks! On 10/6/07, Will Coleda [EMAIL PROTECTED] wrote: On Oct 5, 2007, at 1:35 PM, Maria Fedotova wrote: Hello folks, I wonder if the community would be interested in attaching another garbage collector to the parrot VM. For example, Apache Harmony contains implementation of a parallel garbage collector [1] which is quicker on modern multi-core and SMP systems. If you think this may be technically feasible, I wonder if there are any legal issues which prevent Apache-licensed component to be used with the code licensed under artistic license. I'm currently looking at tools/dev/mk_manifest_and_skip.pl to add GC files to the build process. I'm also trying to dig up how --gc=config option of Configure.pl works. This script automatically generates MANIFEST and MANIFEST.SKIP based on what's checked into the repository; If files are added to the repo, running this tool automatically adds them. [1] http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/ gc_gen/ With best regards, Masha -- Will Coke Coleda [EMAIL PROTECTED] externals_fix.patch Description: Binary data
Re: Parallel GC for parrot - does it make sense?
On Saturday 06 October 2007 13:49:21 Maria Fedotova wrote: I succeeded to merge Harmony tree into my local copy: $ svn propget svn:externals src/gc gen http://svn.apache.org/repos/asf/harmony/enhanced/drlvm/trunk/vm/gc_gen/src Then I fixed Manifest.pm to process external entries correctly and started to understand that MANIFEST is used mainly for bundling of the product. It seems to me that it is not used for Makefile generation. Is it true that config/gen/makefiles/root.in is hand-written? Yes, that's exactly right. After you make the change, re-run perl Configure.pl and you'll get new Makefiles. It should be *fairly* easy to modify, but if you run into trouble there should be someone in #parrot on irc.perl.org who can help you. -- c
Re: Parallel GC for parrot - does it make sense?
Hi, Allison Randal wrote: It's worth exploring, and may lead to other experiments in parallel GC.. Parrot allows multiple different GC systems, so you shouldn't encounter significant problems on the Parrot side, but if you do, let us know and we'll fix them. I don't know if Harmony's parallel GC was designed to be plugged into other systems, though, so you may need to write a wrapper around it (which may lose some of the speed gains). What is the future of Parrot and GC systems ? Are we gonna have in near future similar GCs what the JVM has at this moment: - serial collector - parallel collector - concurrent collector ? That would be good since you can adjust your application for different loads. As well that would increase the time spent how to tune and do maintenance for your app so documentation would be valuable. Im curious, is Parrot a generational type of VM (objects are allocated in generations), similar as the popular JVM ? Rgds, Stefan
Re: Parallel GC for parrot - does it make sense?
The three schemes currently implemented are generational, stop-the-world mark-and-sweep, and incremental mark-and-sweep. The generational GC implementation is not complete yet. The default GC scheme at the moment is stop-the-world mark-and-sweep. For the 1.0 release the default will likely be either incremental or generational, depending on which proves to be the most stable and best performance on average across common use cases. We will definitively need good documentation for this part: - Parrot VM tuning, is it needed, why and when ? - Parrot and JVM, a simple face-to-face comparative description will help a lot of folks coming from Java land and as well sysadmins which are maintaining the JVM options for app servers, for instance. For instance, this would be very interesting how Parrot VM will be configured to run Perl 6... - Parrot's VM options should try to stay as a small set, good documented and not expand in dozens hard to maintain and hard to understand. Thanks for message, Stefan
Parallel GC for parrot - does it make sense?
Hello folks, I wonder if the community would be interested in attaching another garbage collector to the parrot VM. For example, Apache Harmony contains implementation of a parallel garbage collector [1] which is quicker on modern multi-core and SMP systems. If you think this may be technically feasible, I wonder if there are any legal issues which prevent Apache-licensed component to be used with the code licensed under artistic license. I'm currently looking at tools/dev/mk_manifest_and_skip.pl to add GC files to the build process. I'm also trying to dig up how --gc=config option of Configure.pl works. [1] http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/gc_gen/ With best regards, Masha
Re: Parallel GC for parrot - does it make sense?
It's worth exploring, and may lead to other experiments in parallel GC.. Parrot allows multiple different GC systems, so you shouldn't encounter significant problems on the Parrot side, but if you do, let us know and we'll fix them. I don't know if Harmony's parallel GC was designed to be plugged into other systems, though, so you may need to write a wrapper around it (which may lose some of the speed gains). Parrot's Artistic 2.0 license and the Apache 2.0 license are compatible, so you'll have no trouble using them together. (Parts of Artistic 2.0 were directly inspired by Apache 2.0.) Allison Maria Fedotova wrote: Hello folks, I wonder if the community would be interested in attaching another garbage collector to the parrot VM. For example, Apache Harmony contains implementation of a parallel garbage collector [1] which is quicker on modern multi-core and SMP systems. If you think this may be technically feasible, I wonder if there are any legal issues which prevent Apache-licensed component to be used with the code licensed under artistic license. I'm currently looking at tools/dev/mk_manifest_and_skip.pl to add GC files to the build process. I'm also trying to dig up how --gc=config option of Configure.pl works. [1] http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/gc_gen/ With best regards, Masha
Re: Parallel GC for parrot - does it make sense?
On Oct 5, 2007, at 1:35 PM, Maria Fedotova wrote: Hello folks, I wonder if the community would be interested in attaching another garbage collector to the parrot VM. For example, Apache Harmony contains implementation of a parallel garbage collector [1] which is quicker on modern multi-core and SMP systems. If you think this may be technically feasible, I wonder if there are any legal issues which prevent Apache-licensed component to be used with the code licensed under artistic license. I'm currently looking at tools/dev/mk_manifest_and_skip.pl to add GC files to the build process. I'm also trying to dig up how --gc=config option of Configure.pl works. This script automatically generates MANIFEST and MANIFEST.SKIP based on what's checked into the repository; If files are added to the repo, running this tool automatically adds them. [1] http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/ gc_gen/ With best regards, Masha -- Will Coke Coleda [EMAIL PROTECTED]
Re: Parallel GC for parrot - does it make sense?
Stefan Parvu wrote: What is the future of Parrot and GC systems ? Are we gonna have in near future similar GCs what the JVM has at this moment: - serial collector - parallel collector - concurrent collector ? The design document for Parrot's GC system is scheduled to be completed Jan 15th. But, I can give you a preview, since that's more a matter of formalizing existing plans and implementation and cleaning up corner cases. Parrot will have pluggable a GC system (it already does). The GC scheme is chosen when configuring/compiling Parrot, and not swappable at runtime. For the 1.0 release we'll only require that the basic GC schemes be complete and stable. There's plenty of room for other GC schemes to be developed before and after the 1.0 release. Whether they get included in the 1.0 release will depend on how stable they are when we ship. That would be good since you can adjust your application for different loads. As well that would increase the time spent how to tune and do maintenance for your app so documentation would be valuable. Im curious, is Parrot a generational type of VM (objects are allocated in generations), similar as the popular JVM ? The three schemes currently implemented are generational, stop-the-world mark-and-sweep, and incremental mark-and-sweep. The generational GC implementation is not complete yet. The default GC scheme at the moment is stop-the-world mark-and-sweep. For the 1.0 release the default will likely be either incremental or generational, depending on which proves to be the most stable and best performance on average across common use cases. Allison
