Defining anonymous classes

[Raffaello Giulietti]

Mark,

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 
is created.

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.

Regards
Raffaello



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 
> mentioned
> 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 )
>
> regards
> mark
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140819/7e58ae17/attachment.html>