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 c
On Mon, Feb 1, 2010 at 8:20 PM, John Rose 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 instanceo
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). A
On Wed, Jan 27, 2010 at 10:16 AM, John Rose 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 anonymous
> classe
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
T
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
> ... 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
___
ml
On Wed, Jan 27, 2010 at 9:42 AM, Y. Srinivas Ramakrishna
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
> (which ones, if
On Wed, Jan 27, 2010 at 3:42 AM, Y. Srinivas Ramakrishna
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
> (which ones, if
On 27 Jan 2010, at 13:05, Tobias Ivarsson wrote:
> On Wed, Jan 27, 2010 at 12:48 PM, Rémi Forax wrote:
> Le 27/01/2010 02:09, John Rose a écrit :
> > On Jan 26, 2010, at 4:52 PM, Mark Mahieu wrote:
> >
> >
> >> On 26 Jan 2010, at 22:01, John Rose wrote:
> >>
> >>> Shall we do some more? (Just
On Wed, Jan 27, 2010 at 12:48 PM, Rémi Forax wrote:
> Le 27/01/2010 02:09, John Rose a écrit :
> > On Jan 26, 2010, at 4:52 PM, Mark Mahieu wrote:
> >
> >
> >> On 26 Jan 2010, at 22:01, John Rose wrote:
> >>
> >>> Shall we do some more? (Just wondering about it today. No special
> reason... :
Le 27/01/2010 02:09, John Rose a écrit :
> On Jan 26, 2010, at 4:52 PM, Mark Mahieu wrote:
>
>
>> On 26 Jan 2010, at 22:01, John Rose wrote:
>>
>>> Shall we do some more? (Just wondering about it today. No special
>>> reason... :-)
>>>
>> Well, perhaps I should poke my head u
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, an
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 Rose wrote:
>>
>>> On Jan 27, 2010, at 12:30 AM, Patrick Wright wrote:
>>>
>>>
Is the EG considering Anonymous classes for JSR 292?
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
(which ones, if any, specifically?) to be located and why?
thanks!
-- ramki
> 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 jus
On Jan 27, 2010, at 1:03 AM, Patrick Wright wrote:
> On Wed, Jan 27, 2010 at 9:45 AM, John Rose 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
>
> From
> w
On Wed, Jan 27, 2010 at 9:45 AM, John Rose 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 following these
di
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
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman
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
mlvm-dev@o
On Jan 26, 2010, at 4:52 PM, Mark Mahieu wrote:
> On 26 Jan 2010, at 22:01, John Rose wrote:
>> Shall we do some more? (Just wondering about it today. No special
>> reason... :-)
>
> Well, perhaps I should poke my head up and suggest that this project, and
> your own writings on the subject
On 26 Jan 2010, at 22:01, John Rose wrote:
> Shall we do some more? (Just wondering about it today. No special
> reason... :-)
Well, perhaps I should poke my head up and suggest that this project, and your
own writings on the subject in particular, may have turned more heads than you
yet k
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
Perhaps Sun should target more universities in addition to Johannes Kepler
University Linz (JKU). Perhaps more prototypes will arrive that way.
I've asked around and people have said that a google summer of code project
for enhancing the JVM was previously rejected. Has anyone tried to file one
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 inte
Le 26/01/2010 14:02, Raffaello Giulietti a écrit :
> 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?
>
NYI (Not Yet Implemented).
> And what about
> * AnonymousClasses
>
Jdk7 contains
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
mlvm-d
27 matches
Mail list logo
