John Wilson wrote: > What I'm seeing, via this list and others, is that people are making > great strides in understanding how to utilise features in the current > JVM to make dynamic languages faster. The JRuby and Groovy teams seem > to be making progress which may well make this work unnecessary for > them. I'm concerned that a proposal like this will make use of some > redundant information which could be used by some other JVM feature > and by the time it's in the field and usable the problem will have > been solved another way. (I'm also slightly terrified of building > something based on address alignment and assuming that the behaviour > of the hardware will be the same in 5-10 years time).
Speaking for JRuby, the proposed changes have me giddy with anticipation. Sure, there's a lot of these things that we can (and often have) but they're painful, less efficient than they should be, and often have other costs like excess permgen use or heap for lots of generated code. We need help here for these things to be really long-term viable, because better performance, better integration, and better implementations are all going to depend on incrementally improving the way we do things; that's going to be hard when we hit a wall because the JVM is no longer improving. We're pushing the leading edge...and we need to make sure our pushing has an effect, even if it takes a while to trickle down. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
