Defining anonymous classes
raffaello.giulietti at gmail.com
Tue Aug 19 14:31:14 UTC 2014
consider pure code container JVM classes, each one of them holding only
a large bunch (say 16K) of static methods, all with synthetic names and
the same signature (i.e., number of arguments in case of ST). Initially,
the methods are just pre-allocated empty placeholders. As ST methods are
added, removed or modified, these container classes are transformed at
runtime (and later stored as files) by means of java.lang.instrument.
For example, adding a new ST method means transforming one of the empty
methods as to contain the appropriate bytecode. As soon as one container
class becomes full, i.e., when each method contains non-trivial code,
another container class with another large bunch of empty static methods
The ST runtime, of course, needs to keep track of the mapping between
the ST methods and the JVM methods. Note that there's no one-to-one
mapping between ST classes and these container classes. Methods of one
ST class are dispersed between different container classes, probably
even if they bear the same signatures.
This way the number of container classes is drastically reduced but,
alas, more bookkeeping is required.
On 2014-08-18 21:36, Mark Roos wrote:
> Hi John
> Just to keep my use case visible. For my use I convert each Smalltalk
> method to a
> Java class ( inheriting from Object ) which only includes static
> methods. Due to
> how I handle blocks there is often more than one method in each class.
> I do invoke
> static methods from my support classes.
> I use the single class loader plus constant method handles as Remi
> which works well. My only concern is the speed of creating a class.
> I suspect
> that the standard class loader performs some security and validity
> checking which
> the unsafe one does not. GC is not critical except during development
> as code
> is rarely replaced on the fly.
> So my only request might be for a very lightweight class and loader
> perhaps handled
> via an annotation which just holds methods ( or maybe just an array of
> methods )
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mlvm-dev