harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][sablevm] Desing of Class Unloading Support
Date Thu, 09 Nov 2006 14:51:55 GMT
On 11/9/06, Robin Garner <robin.garner@anu.edu.au> wrote:
>
> Geir Magnusson Jr. wrote:
> >
> >
> > Weldon Washburn wrote:
> >>
> >>
> >> On 11/8/06, *Geir Magnusson Jr.* <geir@pobox.com
> >> <mailto:geir@pobox.com>> wrote:
> >>
> >>
> >>
> >>     Weldon Washburn wrote:
> >>      > On 11/7/06, Ivan Volosyuk < ivan.volosyuk@gmail.com
> >>     <mailto:ivan.volosyuk@gmail.com>> wrote:
> >>      >>
> >>      >> On 07 Nov 2006 14:35:55 +0600, Egor Pasko <egor.pasko@gmail.com
> >>     <mailto:egor.pasko@gmail.com>> wrote:
> >>      >> > > I already have one idea how to benefit from movable
> vtables.
> >>      >
> >>      >
> >>      > There would have to be a very compelling argument for making
> >> vtables
> >>      > movable.  Like a business workload that Harmony needs to run
> >>     within the
> >>      > next
> >>      > 12 months.
> >>
> >>     How would a business workload need this directly?
> >>
> >> That's the point.  I can't figure out any compelling story for moving
> >> vtables.  As far as I can tell, its over-engineering.   I would love
> >> to be proven wrong.
> >
> > But isn't this simply an implementation detail of something that is
> > important, namely the class unloading?
> >
> > geir


I have no problem calling it an implementation detail.  Its an important
implementation detail that somehow got mixed into the design conversation.
Worth noting is that ultimately the committer is on the hook for committing
an implementation.  It would be good to have the discussion on moving vtable
implementation before someone spends a bunch of time on it.

While it did come up as an issue in the class-unloading talks I think
> most of us believe it to be orthogonal.
>
> cheers
>
> --
> Robin Garner
> Dept. of Computer Science
> Australian National University
>



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message