Should there be any issues using sun.invoke.anon?

[Mark Roos]

Hi John,  Thanks for the plug.  I feel that I have taken more than I have 
contributed.  Hopefully I'll return
some next week.

As for your comments
         the anonymous class loader is a purely experimental feature, with 
no standard API.  For this reason, you can only use it reliably with MLVM 
builds.
Interesting as it works fine with the public windows build and executes 
with the osx just does not compile ( and its in the jar) 


        What advantage does the use of anonymous classes gain you?  Is 
there a performance advantage?
Well I do have one class per method so that would be 40K plus and they do 
get replaced some.  I heard that there could be a perm gen issue so I just 
went 
this way.  I am interested in the constant loading via the class loader vs 
the constant method handle.  That was the real reason I first went anon. 
But then the
constant mh works fine.  If 100K plus classes is fine then I'll change. 
Though it bruises my minimalist inner child.


        The http://asm.ow2.org framework is an excellent way to spin 
bytecodes. 
Yes I use this now.  Kudos to Remi for his work here. (sorry for the 
spelling, windows machine you know)


        Should we consider anonymous classes  for a future version of JSR 
292 (or another JSR)? 
Probably just if the number of classes allowed is an issue or if loading 
constants is better this way.  To be honest I don't see any
value is have java classes for what I do.  If the  goal is to divorce the 
JVM from java then this is one item.  I would rather see the
need for type correctness in the MH code removed ( and the varArgs more 
explicit) as this contributes only confusion.

On the other had being able to use java as my "op sys" is one of the 
reasons for going this route.  What I need is a good way to
handle box/unbox of java objects and prims from my "boxes" which the JIT 
understands

See you next week
regards
mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110711/9241bd05/attachment.html