From: Godmar Back (gback@cs.utah.edu)
Date: Tue Feb 16 1999 - 18:03:46 EST
>
> Godmar Back wrote:
>
> > >
> > > > For practical reasons, I'm for changing Kaffe rather than egcs.
> > >
> > > Hmmm - kind of contra-productive. There is one reason to use WAT: getting
> > > optimized code with a minimum amount of load/compile time. Any load-time
> >
> > True. However, these are only initial, one-time costs, if
> > I understand it right. And they're far smaller than jitting a method.
> > There is the memory cost.
>
> Maybe its a smaller cost - but it's still a cost which can be avoided by changing
> GCJ.
>
> >
> >
> > > conversion is against that. And if egcs does change its structures, again, we
> > > end up with work on both sides (analyzing egcs changes *and* modifying kaffe
> > > adaption functions). More work for less results.
> > >
>
> A very good point - they made a number of change since I last looked into this.
>
> >
> >
> > Besides, I just don't see how you would want to accomplish this in
> > practice. egcs is very much in flux, Cygnus doesn't include Kaffe patches,
> > do you want to branch off egcs? Viel Spass damit.
> >
> > - Godmar
>
> We certainly don't want to branch off EGCS - but it's possibly to provide the
> patches and even the pre-patches sources of EGCS.
>
> Changing the internals of Kaffe is major work - and changing for a moving target
> when someone else controls it isn't my idea of fun.
>
Certainly not.
I'm just trying to understand what the options are.
So you would be envisioning a set of patched to major releases of egcs.
People would have to build their own version of egcs and would not
be able to use the version that comes with the .rpm/.deb their sysadmin
installed. Bad idea, if you ask me.
On the other hand, if we provide precompiled .so files, things may look
different for the majority of users.
Also, even though it appears logical that Cygnus would not support it,
asking them (publically, on the egcs mailing list) to include a specific
set of patches would not hurt. Especially if the patches are contained
and modular. This would alert people to the possibility of using kaffe
as a run-time, and might create momentum and possibly outside pressure
on Cygnus to accept the patches.
I don't know what the patches are; ideally, they would work in a way that
doesn't impact the ability of the egcs people to make changes on their
part. If they're really modular in this way, they may have a higher chance
of being included. The public statements on the egcs mailing list I
remember where "no plans for Kaffe support" (Per Bothner) and "if changes
for other VMs were to be included, they would have to be modular." (Tom
Troney) I didn't anybody actually say that they're not going include
patches for a competitor's VM. So even though the answer may likely be
no I don't think it'll hurts us to ask (publically). I think we're better
off asking and being rejected than not asking at all. Ideally, the
gcj integration at this point would be at a stage that would allow outside
people to verify that it "works".
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:58:09 EDT