Re: [arch] Interpreter vs. JIT for Harmony VM
Geir> What's an activation record? Compiler speak for a stack frame. http://en.wikipedia.org/wiki/Activation_record Tom
Re: [arch] Interpreter vs. JIT for Harmony VM
> "Steve" == Steve Shih-wei Liao <[EMAIL PROTECTED]> writes: Steve> Harmony JVM needs to be designed to support non-reentrant JITs Steve> as a default. It also needs to be designed to take advantage Steve> of reentrant JITs. This is particularly important as the Steve> industry moves to multicore. What do you mean when you say "non-reentrant JIT"? A JIT that has global variables and assumes it is only running in one thread at a time? Or a JIT that assumes that it won't be interrupted (in a given thread) to do some other piece of work? Or maybe something else? Tom
Re: VM/Class Library Interface (or "Storming the Gates! Take 3!")
> "Graeme" == Graeme Johnson <[EMAIL PROTECTED]> writes: Graeme> Split-class (ClassX & VMClassX) or customized-class solutions (Tim E's Graeme> Kernel classes) are different approaches to solving the same problem. Graeme> Of the two approaches I believe that the customized-class solution Graeme> delivers simpler code and shorter call-paths as it avoids the need for Graeme> any runtime redirection. Graeme> Also, if you ever need to change class shape (e.g. add an extra long Graeme> field to point at a C structure) you're basically forced into the Graeme> customized-class solution. Why not stick to one technique? FWIW we continue to do both approaches in Classpath -- different VMs do different things. In particular in gcj we replace some of the core classes like Class and String with our own versions. The difficulty here is that bug fixes to the shared code must be manually merged. This turns out to be more work than we originally thought it would be; in general these days I try to push us to follow Classpath more closely for this reason. Tom
Re: Code contribution to harmony
Tim Ellison wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. Right on :-) Let's the harmonization process begin :-) -- Stefano.
Re: [arch] Interpreter vs. JIT for Harmony VM
On Nov 8, 2005, at 10:20 AM, Steve Shih-wei Liao wrote: Harmony JVM needs to be designed to support non-reentrant JITs as a default. It also needs to be designed to take advantage of reentrant JITs. This is particularly important as the industry moves to multicore. Is it possible to have some kind of core-affinity for the JIT? So non-reentrant JITs could be used in multicore systems w/o a rewrite? To have clean, easy to maintain Execution Manager interfaces, there needs to be well thought out JIT ABI to C/C++ ABIs. This will allow activation records from JIT code to interoperate with activation records from an interpreter written in C/C++. What's an activation record? (I'd ask "why do they need to interoperate", but I'll save that if your answer doesn't give me a hint...) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [arch] Interpreter vs. JIT for Harmony VM
Here I'm resending my earlier posting in order to have a typo fixed
("excusively" should have been "exclusively"). Thanks for your time:
Good question! I'll reply according to the 4 areas in the previous email:
abstracting over the mode of execution, asynchronous compilation,
reentrancy, and supporting the mixing of JIT and interpreter.
The Execution Manager (EM) could be designed to host both JIT as well as
interpreter. The EM could also contain the execution policy. For example,
interpret exclusively or interpret until certain thresholds are crossed then
JIT. One way of doing this is to have the EM build an internal configuration
data structure to would hold the execution policy. The policy would be
loaded via a *.properties file or even developer time makefile parameters.
There are a number of ways to support asynchronous
compilation/re-compilation. For example, a timer based approach would sample
method hotness for a time interval of "X", then recompile the hotest methods
first in a separate thread. The java app threads continue without
disruption.
Harmony JVM needs to be designed to support non-reentrant JITs as a default.
It also needs to be designed to take advantage of reentrant JITs. This is
particularly important as the industry moves to multicore.
To have clean, easy to maintain Execution Manager interfaces, there needs to
be well thought out JIT ABI to C/C++ ABIs. This will allow activation
records from JIT code to interoperate with activation records from an
interpreter written in C/C++. Although this is messy and tedious work,
getting the ABI issues sorted out early will make development of pluggable
JITs and interpreters much easier. This in turn will allow Harmony to
support a larger number of active developers/committers than would otherwise
be possible.
Steve Liao, Intel Managed Runtime Division
On 11/8/05, Steve Shih-wei Liao <[EMAIL PROTECTED]> wrote:
>
> Good question! I'll reply according to the 4 areas in the previous email:
> abstracting over the mode of execution, asynchronous compilation,
> reentrancy, and supporting the mixing of JIT and interpreter.
> The Execution Manager (EM) could be designed to host both JIT as well as
> interpreter. The EM could also contain the execution policy. For example,
> interpret excusively or interpret until certain thresholds are crossed then
> JIT. One way of doing this is to have the EM build an internal configuration
> data structure to would hold the execution policy. The policy would be
> loaded via a *.properties file or even developer time makefile parameters.
>
> There are a number of ways to support asynchronous
> compilation/re-compilation. For example, a timer based approach would sample
> method hotness for a time interval of "X", then recompile the hotest methods
> first in a separate thread. The java app threads continue without
> disruption.
>
> H
> armony JVM needs to be designed to support non-reentrant JITs as a
> default. It also needs to be designed to take advantage of reentrant JITs.
> This
> is particularly important as the industry moves to multicore. To have
> clean, easy to maintain Execution Manager interfaces, there needs to be well
> thought out JIT ABI to C/C++ ABIs. This will allow activation records from
> JIT code to interoperate with activation records from an interpreter written
> in C/C++. Although this is messy
> and tedious work, getting the ABI issues sorted out early will make
> development of pluggable JITs and interpreters much easier. This in turn
> will allow Harmony to support a larger number of active
> developers/committers than would otherwise be possible. Steve Liao, Intel
> Managed Runtime Division
>
>
> On 10/31/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >
> > So what does that interface look like? Have any suggestions?
> >
> > geir
> >
> > On Oct 30, 2005, at 8:51 PM, Steve Shih-wei Liao wrote:
> >
> > > Sure. (I had been out of country until last weekend.)
> > > Since there is a reason to support both JITs and interpreters, we
> > > should
> > > keep the option open to have interpreters and JITs.
> > >
> > > I think the modular interface from the VM core to Execution Engines
> > > should
> > > support both JITs and interpreters. Execution Engine interface should
> > > abstract over the mode of execution. This will cover a wide
> > > spectrum of the
> > > market segments. Cell phone environment may demand an interpreter or a
> > > light-weight JIT with small memory footprint. Server market segment
> > > probably
> > > prefers a powerful JIT.
> > >
> > > The issues of supporting both JITs and interpreters include:
> > >
> > > - Asynchronous compilation: Execution Manager can have a time-based
> > > interrupt to invoke Execution Engines to recompile.
> > >
> > > - Re-entrant JIT: Many JITs are not re-entrant. When running, for
> > > instance,
> > > MTRT in SPECJVM, because multiple threads are running, multipl
Re: [arch] Interpreter vs. JIT for Harmony VM
Good question! I'll reply according to the 4 areas in the previous email: abstracting over the mode of execution, asynchronous compilation, reentrancy, and supporting the mixing of JIT and interpreter. The Execution Manager (EM) could be designed to host both JIT as well as interpreter. The EM could also contain the execution policy. For example, interpret excusively or interpret until certain thresholds are crossed then JIT. One way of doing this is to have the EM build an internal configuration data structure to would hold the execution policy. The policy would be loaded via a *.properties file or even developer time makefile parameters. There are a number of ways to support asynchronous compilation/re-compilation. For example, a timer based approach would sample method hotness for a time interval of "X", then recompile the hotest methods first in a separate thread. The java app threads continue without disruption. Harmony JVM needs to be designed to support non-reentrant JITs as a default. It also needs to be designed to take advantage of reentrant JITs. This is particularly important as the industry moves to multicore. To have clean, easy to maintain Execution Manager interfaces, there needs to be well thought out JIT ABI to C/C++ ABIs. This will allow activation records from JIT code to interoperate with activation records from an interpreter written in C/C++. Although this is messy and tedious work, getting the ABI issues sorted out early will make development of pluggable JITs and interpreters much easier. This in turn will allow Harmony to support a larger number of active developers/committers than would otherwise be possible. Steve Liao, Intel Managed Runtime Division On 10/31/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > So what does that interface look like? Have any suggestions? > > geir > > On Oct 30, 2005, at 8:51 PM, Steve Shih-wei Liao wrote: > > > Sure. (I had been out of country until last weekend.) > > Since there is a reason to support both JITs and interpreters, we > > should > > keep the option open to have interpreters and JITs. > > > > I think the modular interface from the VM core to Execution Engines > > should > > support both JITs and interpreters. Execution Engine interface should > > abstract over the mode of execution. This will cover a wide > > spectrum of the > > market segments. Cell phone environment may demand an interpreter or a > > light-weight JIT with small memory footprint. Server market segment > > probably > > prefers a powerful JIT. > > > > The issues of supporting both JITs and interpreters include: > > > > - Asynchronous compilation: Execution Manager can have a time-based > > interrupt to invoke Execution Engines to recompile. > > > > - Re-entrant JIT: Many JITs are not re-entrant. When running, for > > instance, > > MTRT in SPECJVM, because multiple threads are running, multiple > > JITTing may > > happen concurrently if there is no locking. The Execution Manager > > can put > > locks before each JITTing in order to ensure that no multiple > > JITTing is > > going on concurrently. > > > > But if we want to allow concurrent JITTing, I think the JIT needs > > to be > > changed to stateless and some VM data structures that a JIT > > accesses needs > > to be changed to allow concurrency. > > > > - For the mixing of native frames and Java frames, who should own > > the stack > > layout (format of JIT and interpreter stack layout)? Probably VM? For > > example, GC should talk to that owner for the root set. > > Any thoughts? > > Steve Liao, Intel Managed Runtime Division > > On 10/2/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > >> > >> What don't you emerge it? :) > >> > >> geir > >> > >> On Oct 2, 2005, at 7:17 PM, Steve Shih-wei Liao wrote: > >> > >> > >>> Good email thread! Lots of different opinions have been expressed. > >>> It seems > >>> there are valid reasons to support both JIT and interpreter in > >>> Harmony VM. > >>> Looking into the future, it seems the Harmony modular framework > >>> needs to > >>> allow both JIT and interpreter modules to be plugged in. > >>> Designing a VM modular framework to accommodate JIT as well as > >>> interpreter > >>> brings up entirely new design topics. Perhaps a new thread on these > >>> issues > >>> will emerge. > >>> Steve Liao, Intel Managed Runtime Division > >>> On 9/23/05, Graeme Johnson <[EMAIL PROTECTED]> wrote: > >>> > >>> > > "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote on 09/22/2005 > 06:34:44 AM: > > > > > [SNIP] > > > > > >> Geir> Basic thought is yes, I always figured we'd have this > >> pluggable, with > >> Geir> an interpreter for ease of porting, and then platform- > >> specific JIT. > >> > >> It seems to me that there's a design question here. For > >> instance, if > >> you want to eventually take interpreted code and compile it > >> (when it > >> is "hot"), for full pluggability your JIT(s) and
Re: Code contribution to harmony
AWESOME!! thanks guys. -- dims On 11/8/05, Tim Ellison <[EMAIL PROTECTED]> wrote: > Tim Ellison wrote: > > I'll post the URL for the VM download (as soon as I know it) as a > > follow-up to this mail -- it could take a couple of days to organize. > > Hey, the DeveloperWorks download is available now: > http://www.ibm.com/developerworks/java/jdk/harmony > > > Any questions just shout. > > Regards, > Tim > > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > -- Davanum Srinivas : http://wso2.com/blogs/
Re: Code contribution to harmony
Tim Ellison wrote: > I'll post the URL for the VM download (as soon as I know it) as a > follow-up to this mail -- it could take a couple of days to organize. Hey, the DeveloperWorks download is available now: http://www.ibm.com/developerworks/java/jdk/harmony Any questions just shout. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [modularity] OSGi or ? (was Re: half-baked idea? j2me)
Tim Ellison wrote: > I understand that the topic relates to the mechanics of achieving the > componentization rather than the content of the components, but I > proposed a componentization split for the J2SE libraries a while ago [1] > and the final version ended up on the Harmony wiki [2]. That was done > only with J2SE in mind, by trying to define the large 'functional units' > of the class library code. (I feel like I keep recycling old > messages... so apologies for the repetition.) I've had something like that in place for Kaffe for a while during a few years, but I found the manual updating of component sets during the rush of development on GNU Classpath to be, ugh, somewhat boring work, and settled for for an approach where the list of classes to be compiled can be pruned down, or left to the compiler to pull in the dependencies. I am wondering if the osgi toolkits support some more automated ways of partitioning libraries into separate, coupled artefacts. I've heard on the classpath list, that such tools exist[1], but it seems that I've my google skills are not good enough to locate them :) cheers, dalibor topic [1] http://lists.gnu.org/archive/html/classpath/2005-10/msg00180.html
Re: Code contribution to harmony
Geir Magnusson Jr. wrote: > Thanks Tim! > > 4) To that end, I can think of a few things we can do to get started : > > a) Get our own current crop of VMs working with it - bootVM and jcheVM. > And I am hoping a lot to see a combination of both emerge ... > b) Help to get Kaffe working with the library interface - see what it > takes to get Kaffe to support this interface as well (if they want), so > we have a more mature free VM that supports the interface. > > c) Help to get GNU Classpath supporting the interface (if they want) > so that GNU Classpath can run on the evaluation VM. +1 to all of the above. The fun's just starting. > On Nov 8, 2005, at 5:49 AM, Tim Ellison wrote: > > I'm delighted to be able to make a code contribution to the Harmony > project on behalf of IBM. The code comprises a concrete implementation > of the interface between virtual machine and class library that we have > been discussing recently, together with a set of core Java classes. The > aim is to ground the discussion in reality and provide an opportunity > for people to collaborate on enhancements and improvements to actual > code. The Java classes are a subset of Java SE 1.4.2 APIs sufficient to > run Ant and the Eclipse Java compiler, to provide a basic self-hosting > environment. Some of the types are simply stubs to enable full > recompilation of the Java code. The ZIP also includes HTML > documentation for the VM interface. Awesome, thanks Tim & team. cheers, dalibor topic
Re: Code contribution to harmony
Thanks Tim! A few comments, wearing my Apache hat of course (n.b I am an IBM employee as well). 0) We need to go through the bulk contribution process for this donation (of course). I have an outstanding to-do on that, which is to wrap up the bulk contrib rules. I have a proposal that I'll bring to the dev list later today. Many of the following statements are made with the assumption that we will work through this process successfully, and the project will vote to accept this contribution. 1) This is our most significant donation we have received to date (in terms of maturity and size, I think) and I encourage everyone to start to play with it. I think of Harmony as a big freight train and with this contribution builds on the contributions of Dan, Archie, David, and all the others and the train is starting to move. The nice thing about a lot of mass is that even small velocities result in very large momentum :) 2) Combined with the VM that IBM is making available _for evaluation_, there is a very low barrier to entry to get people up and working with this. Tim and his team have gone to great pains to make this easy to evaluate and use (only to be foiled at the end by our 10MB upload limit on JIRA, hence the two zip files...) so I encourage everyone to take some time to play, inspect and of course, ask questions. 3) I want to emphasize that IBM is making their VM available to help us evaluate and develop this further until we get our own open source VM underneath it. The VM (for which a link will be posted later) is not being contributed to the project, or licensed for any other use. It is proprietary software under a proprietary license. It is useful to us because it supports the VM/classlibrary interface that the IBM donation implements, so we can start evaluation and testing immediately. 4) To that end, I can think of a few things we can do to get started : a) Get our own current crop of VMs working with it - bootVM and jcheVM. b) Help to get Kaffe working with the library interface - see what it takes to get Kaffe to support this interface as well (if they want), so we have a more mature free VM that supports the interface. c) Help to get GNU Classpath supporting the interface (if they want) so that GNU Classpath can run on the evaluation VM. The point here is to continue to focus on our cross-project interoperability and modularity interests, with this important interface as a starting point. The other benefit of this is that we can start gump-ing this stuff ASAP :) I'm sure I'll have things I want to add once I hit "send"... Yay! geir On Nov 8, 2005, at 5:49 AM, Tim Ellison wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. The code comprises a concrete implementation of the interface between virtual machine and class library that we have been discussing recently, together with a set of core Java classes. The aim is to ground the discussion in reality and provide an opportunity for people to collaborate on enhancements and improvements to actual code. The Java classes are a subset of Java SE 1.4.2 APIs sufficient to run Ant and the Eclipse Java compiler, to provide a basic self-hosting environment. Some of the types are simply stubs to enable full recompilation of the Java code. The ZIP also includes HTML documentation for the VM interface. I've uploaded the contribution here: http://issues.apache.org/jira/browse/HARMONY-14 The expected MD5 sums are: 73ade240df20dec481806130fc8b4875 *Harmony-contribution_Part-1-of-2.zip bc9117d9b4af113eaf5250883d1ce669 *Harmony-contribution_Part-2-of-2.zip A number of people were involved with getting the code ready for contribution (too many to name individually!), and they have done a fine job. There is still plently of work to do; for example, we renamed some code to "Hy", but some still has a "com.ibm" prefix. The code needs bringing up to the project goal of supporting 5.0 APIs. It is targeted at Windows and Linux on Intel 32-bit machines. Now it is everyone's code, join in! In the meantime we are working on making a VM available for download (under a binary evaluation license) from IBM's DeveloperWorks site that implements the class library interface. By getting the VM and unzipping into the same directory you can run the contributed code and try out your changes. I'll post the URL for the VM download (as soon as I know it) as a follow-up to this mail -- it could take a couple of days to organize. Just to avoid confusion, the DeveloperWorks VM not a regular IBM JRE. It is a VM being made available to enable Harmony development and is _not_ a contribution. Regards, Tim - -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuP
Code contribution to harmony
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm delighted to be able to make a code contribution to the Harmony project on behalf of IBM. The code comprises a concrete implementation of the interface between virtual machine and class library that we have been discussing recently, together with a set of core Java classes. The aim is to ground the discussion in reality and provide an opportunity for people to collaborate on enhancements and improvements to actual code. The Java classes are a subset of Java SE 1.4.2 APIs sufficient to run Ant and the Eclipse Java compiler, to provide a basic self-hosting environment. Some of the types are simply stubs to enable full recompilation of the Java code. The ZIP also includes HTML documentation for the VM interface. I've uploaded the contribution here: http://issues.apache.org/jira/browse/HARMONY-14 The expected MD5 sums are: 73ade240df20dec481806130fc8b4875 *Harmony-contribution_Part-1-of-2.zip bc9117d9b4af113eaf5250883d1ce669 *Harmony-contribution_Part-2-of-2.zip A number of people were involved with getting the code ready for contribution (too many to name individually!), and they have done a fine job. There is still plently of work to do; for example, we renamed some code to "Hy", but some still has a "com.ibm" prefix. The code needs bringing up to the project goal of supporting 5.0 APIs. It is targeted at Windows and Linux on Intel 32-bit machines. Now it is everyone's code, join in! In the meantime we are working on making a VM available for download (under a binary evaluation license) from IBM's DeveloperWorks site that implements the class library interface. By getting the VM and unzipping into the same directory you can run the contributed code and try out your changes. I'll post the URL for the VM download (as soon as I know it) as a follow-up to this mail -- it could take a couple of days to organize. Just to avoid confusion, the DeveloperWorks VM not a regular IBM JRE. It is a VM being made available to enable Harmony development and is _not_ a contribution. Regards, Tim - -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDcILEQeoJoFeTSY8RAosaAJ4wnnCaMDb9faTA52UGfxUGLqEOEgCg4ByR lCoq7wUHcDbd/sJxWBiLs60= =E8W4 -END PGP SIGNATURE-
[jira] Updated: (HARMONY-14) Contribution of interface and core classes code
[ http://issues.apache.org/jira/browse/HARMONY-14?page=all ] Tim Ellison updated HARMONY-14: --- Attachment: Harmony-contribution_Part-2-of-2.zip This part contains third-party code are not being relicensed, but are compatible with the ASL. Details are in the combined directory readmes. > Contribution of interface and core classes code > --- > > Key: HARMONY-14 > URL: http://issues.apache.org/jira/browse/HARMONY-14 > Project: Harmony > Type: New Feature > Components: Contributions > Reporter: Tim Ellison > Assignee: Geir Magnusson Jr > Attachments: Harmony-contribution_Part-1-of-2.zip, > Harmony-contribution_Part-2-of-2.zip > > Here's a contribution, which I will describe on the mailing list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-14) Contribution of interface and core classes code
[ http://issues.apache.org/jira/browse/HARMONY-14?page=all ] Tim Ellison updated HARMONY-14: --- Attachment: Harmony-contribution_Part-1-of-2.zip To work around the 10Mb upload limit on JIRA I had to split the zip into two parts. Please download both parts and unzip at the same location. That will create the files under a new directory called 'Harmony'. > Contribution of interface and core classes code > --- > > Key: HARMONY-14 > URL: http://issues.apache.org/jira/browse/HARMONY-14 > Project: Harmony > Type: New Feature > Components: Contributions > Reporter: Tim Ellison > Assignee: Geir Magnusson Jr > Attachments: Harmony-contribution_Part-1-of-2.zip > > Here's a contribution, which I will describe on the mailing list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HARMONY-14) Contribution of interface and core classes code
Contribution of interface and core classes code --- Key: HARMONY-14 URL: http://issues.apache.org/jira/browse/HARMONY-14 Project: Harmony Type: New Feature Components: Contributions Reporter: Tim Ellison Assigned to: Geir Magnusson Jr Here's a contribution, which I will describe on the mailing list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Apache Harmony welcomes Archie Cobbs as our newest committer
Congratulations! On Mon, 2005-11-07 at 22:13 -0500, Geir Magnusson Jr. wrote: > The Apache Harmony PPMC is proud to announce Archie Cobbs as our > newest Apache Harmony committer, and look forward to seeing him > continue his work on jcheVM (now in sandbox/contribs/jchevm), as well > as other areas of his interest. > > Archie has shown a long-standing and broad-ranging interest in the > project, and this will allow him to continue working on his initial > contribution. We believe he is an excellent addition to the project > and will help others in the community with his experience and knowledge. > > Congratulations, > > The Apache Harmony PPMC > -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? I think so Brain, but isn't that why they invented tube socks? smime.p7s Description: S/MIME cryptographic signature
RE: Leadership and direction
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: >> We're all in this together. > Amen Ah men??? *** Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message. ***
