I thought I would throw my $0.02 in on this (at the risk of sounding
like an ignoramus !).
I work on Drools, and we have also had the function per class per
classloader issue (it is typical to have 1000's of rules) - this is
quite an unpleasant amount of overhead (we have ways around it - but
in a sense we are kind of not using the VM bytecode to its full
potential). The aggregation of functions into statics in some "unit"
of compilation is sometimes doable (but for dynamic reasons not the
general solution).
I think Atilla hit the nail on the head:
> > Functions being first-class objects in most of languages we discuss
> > here, their usual implementation is to generate an on-the-fly class,
> > i.e. "class 0a9cee3
Unless I am mistaken, this ties in with Charles Nutters request/
support for "free floating" method bytecode (not attached to a class -
excuse my ignorance in terminology !).
I think dynamic invocation is important, but this other idea of
functions in byte code probably would be the other bit that makes
everything just rosy for most languages. Given that each language
implements OO its own way (if its OO at all, which it may not even
be !) and does not often map neatly to the Java class design (no
surprise - OO is always open to interpretation).
So this could serve as a nice building block. I am totally ignorant of
the other ramifications in terms of loading/unloading, scope and
security - but at first look, being able to generate, and dynamically
invoke a chunk of code which is not attached to a class (and therefore
can be created "lite" and quickly discarded if not needed) sounds
fantastic and an almost general solution. Without this, we tend to
find ourselves building a VM within a VM (not always a great idea !),
rather then leaning on the superb engineering put into the JVM
itself.
Michael.
On Jan 18, 12:30 am, "John Wilson" <[EMAIL PROTECTED]> wrote:
> On Jan 17, 2008 1:19 PM, Attila Szegedi <[EMAIL PROTECTED]> wrote:
>
> > Functions being first-class objects in most of languages we discuss
> > here, their usual implementation is to generate an on-the-fly class,
> > i.e. "class 0a9cee3478 implements Function { ... }" and instantiate
> > exactly one instance of it to pass around as said first-class object.
>
> > If we want to have our functions to be garbage collectibe with a
> > single function granularity, then the class for each one of them needs
> > to be loaded in its own class loader that only loads that class and
> > nothing else . And that's what feels unnecessarily convoluted (having
> > one classloader per class) and raises the requirement for some
> > "lightweight method objects".
>
> One thing I have considered is aggregating all these
> closures/lambda/etc in a compilation unit as static methods on a
> single class. This means that you amortise the cost of a classloader
> over several methods. Instances of the function object delegate to the
> static method. The cost is, obviously, delayed GC of the "mothership"
> class. Of course, if you can dynamically create new functions this
> won't help.
>
> John Wilson
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
