On Sep 4, 2008, at 12:29 AM, Charles Oliver Nutter wrote:
> Attila Szegedi wrote: >> So, on the first sight, it appears to me that TraceMonkey's type >> specialization is the one feature from these three new JS engines >> that >> would make sense in JVM dynamic language runtimes. > > I've toyed with these techniques in JRuby before and always came > back to > the same point: yes, they could make things faster by varying degrees, > but in no case was it worth the pain of managing all that transient > code. That is, until anonymous classloading came along. > > IMHO the biggest things we need to make easier on JVM: > > - make it easier to generate bytecode...ASM and friends mostly solve > this, but I think we need some frameworks, DSLs or somesuch to aid > it a > bit more > - make it absolutely trivial to load new bytecode into the system in > such a way that it can enlist in optimizations > - make it TOTALLY TRANSPARENT that something like PermGen even exists. > PermGen as a separate memory space is an abomination and needs to be > eliminated. Spot on. Code is data. If it were easy to load new snippets of code into the JVM and have them GCed when not used, I'd be much less uneasy about creating a bunch of type-specialized methods from the same source code; heck, I'd probably even have them being soft-referenced if possible (as they're just a optimized representation of something else and can be regenerated if needed) so that they can also be reclaimed for memory. Attila. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
