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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
