Re: indy and tailc

2010-02-02 Thread Rémi Forax
Le 02/02/2010 03:20, John Rose a écrit : On Jan 31, 2010, at 11:19 PM, Charles Oliver Nutter wrote: The other use case, which I did not attempt, was in regenerating call sites a la the DLR's DynamicSite logic (which repeatedly regenerates a call site with a series of instanceof checks,

Re: indy and tailc

2010-02-01 Thread John Rose
On Jan 31, 2010, at 11:19 PM, Charles Oliver Nutter wrote: The other use case, which I did not attempt, was in regenerating call sites a la the DLR's DynamicSite logic (which repeatedly regenerates a call site with a series of instanceof checks, to specialize the call paths iteratively).

Re: indy and tailc

2010-02-01 Thread Charles Oliver Nutter
On Mon, Feb 1, 2010 at 8:20 PM, John Rose john.r...@sun.com wrote: On Jan 31, 2010, at 11:19 PM, Charles Oliver Nutter wrote: The other use case, which I did not attempt, was in regenerating call sites a la the DLR's DynamicSite logic (which repeatedly regenerates a call site with a series of

Re: indy and tailc

2010-01-31 Thread Charles Oliver Nutter
On Wed, Jan 27, 2010 at 10:16 AM, John Rose john.r...@sun.com wrote: They also provide a way to do something like bytecode-level templating, since CP elements can be varied while the rest of the code is held fixed.  I hope somebody experiments with loop customization at some point, using

Re: indy and tailc

2010-01-27 Thread Patrick Wright
Hi John And what about * AnonymousClasses The POC is in there.  Integration with method handles requires interpreter compiler work. Is the EG considering Anonymous classes for JSR 292? Thanks Patrick ___ mlvm-dev mailing list

Re: indy and tailc

2010-01-27 Thread Patrick Wright
On Wed, Jan 27, 2010 at 9:45 AM, John Rose john.r...@sun.com wrote: On Jan 27, 2010, at 12:30 AM, Patrick Wright wrote: Is the EG considering Anonymous classes for JSR 292? No, sorry.  Should we be... what's the use case?  -- John I'm not a language implementor (maybe someday...), but

Re: indy and tailc

2010-01-27 Thread Patrick Wright
1. Method handles provide a better replacement for the swarm of tiny classes. 2. Hotspot is in the process of weaning itself off of perm gen.  One of the main features of perm-gen is that its objects never move except during full GC, and the code cache relied on this invariant until just

Re: indy and tailc

2010-01-27 Thread Rémi Forax
Le 27/01/2010 10:16, John Rose a écrit : On Jan 27, 2010, at 1:03 AM, Patrick Wright wrote: On Wed, Jan 27, 2010 at 9:45 AM, John Rosejohn.r...@sun.com wrote: On Jan 27, 2010, at 12:30 AM, Patrick Wright wrote: Is the EG considering Anonymous classes for JSR 292?

Re: indy and tailc

2010-01-27 Thread Rémi Forax
Le 27/01/2010 10:25, Patrick Wright a écrit : 1. Method handles provide a better replacement for the swarm of tiny classes. 2. Hotspot is in the process of weaning itself off of perm gen. One of the main features of perm-gen is that its objects never move except during full GC, and the

Re: indy and tailc

2010-01-27 Thread Ismael Juma
On Wed, Jan 27, 2010 at 9:42 AM, Y. Srinivas Ramakrishna y.s.ramakris...@sun.com wrote: Patrick Wright wrote: ... Glad to hear that perm gen will eventually go away. Could you elaborate a little on why it would be nice if the perm gen went away? Where would you like its current contents

Re: indy and tailc

2010-01-27 Thread Y. Srinivas Ramakrishna
... perm gen ... go away. Thanks for all the responses. The bottom line appears to be: please do the needful in the JVM, don't tell me (the user) to size the perm gen explicitly. We'll investigate how we can make that happen. thanks. -- ramki ___

Re: indy and tailc

2010-01-27 Thread John Rose
On Jan 27, 2010, at 8:10 AM, Thomas E Enebo wrote: (exact details of what is stored in permgen is fuzzy to me -- some dictionary for class names and some internalized form of the class bytecode??) It's a part of the heap; it contains mostly metadata, notably classes and methods. (It also

Re: indy and tailc

2010-01-27 Thread John Rose
On Jan 27, 2010, at 2:52 AM, Rémi Forax wrote: The problem with the bytecode templating provided by anonymous class is that you can't change the bytecode operations. The bytecode ops are typed (areturn, ireturn, freturn, etc) therefore you can't really patch class unless you only relies

indy and tailc

2010-01-26 Thread Raffaello Giulietti
What is the current status of tailcalls meet invokedynamic? I mean, not the interesting entry in John's blog but the status in the implementation? And what about * AnonymousClasses * ImmediateWrappers * TupleSignatures ___ mlvm-dev mailing list

Re: indy and tailc

2010-01-26 Thread John Rose
On Jan 26, 2010, at 5:02 AM, Raffaello Giulietti wrote: Good questions; thanks Raffaello. What is the current status of tailcalls meet invokedynamic? I mean, not the interesting entry in John's blog but the status in the implementation? It's not yet started. It requires some pretty

Re: indy and tailc

2010-01-26 Thread John Rose
On Jan 26, 2010, at 2:12 PM, Mohamed Bana wrote: Perhaps Sun Well, it's probably perhaps Oracle any time now; we'll see how things shake out. In any case, Sun doesn't do such side-projects, so much as they are created by individual overworked but entrepreneurial engineers and engineering