Re: [ve-dev] Re: Future of VE

[Rich Kulp <richkulp@xxxxxxxxxx>]

Hi,

There was also another reason so many
VMs.

1. Each project could be for a different JVM version or type (Sun, IBM, etc.), so it would need a different jvm for each
2. Each project can have a different classpath. If we used Equinox (which was not available at the time VE was first developed)  it may be possible to handle this.
3. But there is a problem with Introspection used by JEM. java.beans.Introspector tries to use the classloader of the class being introspected. It also tries to cache with a weak reference to the class and classloader. But there is a flaw in the logic in that the classloader and class can never be GC'ed because the introspector may use a weakhashmap on the class as the key, but the value of the map is a GenericBeanInfo, which has a HARD reference to the class through various fields. So it will never go away. There would need to be a cleanup mechanism need to flush the caches. Unfortunately the public methods only allow flushing the entire cache (including those for classes of other projects that haven't changed), or flushing a specific class. The problem with flushing a specific class is that you don't know all of the classes for the "project" that may of been introspected, even introspected as a side-effect. So the classloader and classes would stay loaded even though no one is using them. A "cheat" method would be to use reflection and get the private caches, walk through the keys (which are classes) and remove those classes that are loaded from the classloaders that are "going away" on a classpath change. It would need to be careful because in the future the caches may change name, but seriously I doubt it. Introspection is pretty mature and hasn't changed in a long time.
4. There are some statics that are stored in the java.lang, etc. level which may interfere with each other between the different projects.

These are things that need to be thought
 about. Though the idea of separate classloaders is a good one. JEM
would need to be modified such that it understands classloaders. Right
now it only loads classes from the application class loader. So the "class
factories" would need to become "class loader" proxies instead.

Thanks,
Rich

"David J. Orme" <djo@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

09/14/2007 09:15 AM

Please respond to
Discussions people developing code for the Visual Editor project        <ve-dev@xxxxxxxxxxx>

To	Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>
cc
Subject	Re: [ve-dev] Re: Future of VE

Hi Philippe (et al),

First, I'm really glad to see this groundswell of support for VE!  Thanks
to everyone who's picked it up.

Second, regarding having multiple remote VMs, I wanted to provide a tiny
bit of context and history on the decision to use multiple remote VMs:

We were having trouble with the remote VMs crashing on some platforms.
 In this case, the startup time to restart the remote VM was obvious
and ugly.  So we decided to cache remote VMs in the background so
that if one dies we can immediately switch to a new one, then start another
one in the background.

Hope this helps,

Dave Orme 
----- Original Message -----
From: Steve Robenalt <steve@xxxxxxxxxxxxxx>
To: ve-dev@xxxxxxxxxxx
Sent: Thursday, September 13, 2007 11:10:30 PM GMT-0600
Subject: [ve-dev] Re: Future of VE

Hi Philippe,

1) Nightly builds make sense, though we might want to adjust that based
on actvity. At my day job, we use a Cruise Control build server with a
web front end, which allows anyone who is authorized to schedule a 
build. I think it would be best to set up something like that - regular
builds as well as on-demand. I'm not sure how much work it will be to 
set it up, but hopefully, it won't take too long.

2) I appreciate your offer to help with getting the builds going. I 
found a couple of documentation pages that helped me identify my primary
problems, but may still need help. I had planned to ping Nick Boldt 
anyway since he handles a much more complex build than that of VE.

3) I agree that committer calls and IRC or similar would be a good idea.
My only issue is that my availability is limited for IRC since my day 
job blocks all IM traffic (I'm on US Pacific time zone). My best times
are early morning and late evening.

4) Bug triage would be a good idea; I would particularly like to measure
the number and severity of the bugs in areas of the code where we would
be better off replacing them.

5) I also agree regarding the remote VM - we should be able to use a 
single remote VM and update its contents on demand. If the remote VM ran
Equinox as a basis, we could configure it to dynamically load and unload
plugins via remote provisioning.

There are a lot of other improvements that can be made, so I'm glad to
see this momentum forming around VE. Also, Chris Aniszczyk is trying to
build up some interest in focusing the next bug day on VE.
http://mea-bloga.blogspot.com/2007/09/ve-and-33.html
Thanks Chris!

- Steve Robenalt


ve-dev-request@xxxxxxxxxxx wrote:
> Date: Thu, 13 Sep 2007 08:17:39 -0700
> From: "Philippe Ombredanne" <pombredanne@xxxxxxxxx>
> Subject: RE: Future of VE was [[ve-dev] Re: ve-dev Digest, Vol 31,
>         Issue 1]
> To: "'Discussions people developing code for the Visual Editor
>         project'"        <ve-dev@xxxxxxxxxxx>
> Cc: 'Nick Boldt' <codeslave@xxxxxxxxxx>, 'Erik Hecht'
>         <erik@xxxxxxxxxx>
> Message-ID: <060401c7f619$467cd570$0dfbfdc0@computer>
> Content-Type: text/plain;        charset="us-ascii"
>
> Hi Steve:
> And thank you for your detailed answer!
>   
>> > I have spent a lot of the time since the last CVS checkin
on issues 
>> > related to the build of VE, to ongoing testing, and to 
>> > building a deeper  understanding of VE internals to
resolve some
>>     
> runtime
>> > problems. I'm in the process of preparing a VE 1.3.0 download
page,
>>     
> which will be a
>> > milestone build, rather than a true release. It will be usable
with 
>> > Europa, but as my platforms for testing are limited, I'd
like to get 
>> > some feedback on its current state before deciding how much
>> > additional work is necessary before it can be considered
>>     
> release-ready. To this
>> > end, if anyone is able to give it a serious workout on a
Linux or Mac 
>> > platform and post feedback here, it would be very helpful
to me.
>>     
> I think we should realease nightlies or weeklies, vene before 
> promoting to a misletone so that folks can tests it. As far as 
> building in concerned this is an area where I am comfortable, and
Nick 
> Boldt may be able to chip in a bit too too.
>> > Since you have already contacted me separately regarding
becoming a 
>> > committer, I know you are interested in helping.
>>     
> Of course! There is alareday a ptach and a link to a build there:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=202562 It includes the
> patch contributed by Erik Hecht (Erik btw, could you subcribe to this
> list and create a bugzilla account
>> > For those subscribing to this list, the project could use
additional
>>     
> committers to
>> > help move it along at a faster pace.
>>     
> I think that getting back in a groove of making frequent builds 
> available (at the minimum monthly, to be not too ambitious) , getting
> some scheduled committers calls and IRC meetings, and starting to
do 
> some serious triage on the bugs could go a long way.
>> > In particular, since I was unable to commit 
>> > to the Europa release based on build issues at the time,
I'd like to 
>> > make sure that VE stands a good chance of making it into
the Ganymede 
>> > release train.
>>     
> Once again this an area where help is readily avaialble.
>> > There are lots of things that need to be done, 
>> > and since  my day job doesn't include developing VE,
I need to do my
>>     
> work in
>> > evening and weekend time, so it doesn't go as quickly as
I would like.
>>     
> same here, and I think that getting an all volunteer project roaster
> is a true blessing.
>> > There are many other uses to which VE could be put based
on the 
>> > appropriate level of community involvement - anyone who would
like to 
>> > step up and help would be welcome. If you are interested,
>> > please respond to this mailing list (rather than directly
to me) and
>>     
> I'll do
>> > my best to monitor the list and respond in a timely fashion.
>>     
> As I said, I am interested. Erik stated to me he was too. So has Nick
> and a few others. There are also a few smaller improvements that could
> go a long long way in making VE better. One is getting rid of the
> multi-VM-one-per-editor architecture to get to something slimmer and
> less resource hungry.
>> > Many of the  historic VE committers have other responsibilities
these
>>     
> days and can't devote
>> > the time the project needs, so it is a good time for the
community to
>>     
> step up. Exactly. I am aalso trying to reach out to companies that
> have adopted VE in their products. They would have a vested interest
> in the project health. Companies like Canoo and Nokia come to mind.
> There must be many more. Many linux and eclipse distro shipped VE,
and 
> I have been and will continue shipping VE in EasyEclipse at the minimum.
> -- Cheers Philippe
>   

_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev