* John Rose:
> But, in order to respect the "general aim" you are mentioning, I have
> unhoisted one of the two words from the Class instance itself. This
> will cause a minor slowdown in JSR 292 use cases.
What about using ClassValue for the various caches instead?
enumConstants and enumConstan
On 12/12/2011 05:38 PM, Charles Oliver Nutter wrote:
> I'm still of the opinion that you shouldn't fix it, or at least
> shouldn't demote "noisy" call sites to never optimize. It's not
> common, but there are Ruby programs that may define a new class or
> method at runtime even at steady state. Not
I review the output message. I come to know what the error has come from.
In fact, when I did "make setup", some patches which had already been in the
source rep was not popped at all. relative output is:
-
cd ../..; bash patches/make/each-patch-repo.sh \
I went to the /patches/make directory and executed the make command as follows.
1) make setup, to create symbolic link and set guard. The last output is:
# report what happened:
cd ../..; bash patches/make/each-patch-repo.sh 'hg qselect; hg qunapplied'
+ (cd sources/.; h
Oh, and for closure on this thread...
The benchmark I was looking at did indeed invalidate too frequently.
In this particular case, it was creating a new "singleton" class at
runtime for every iteration, and the subsequent method definitions
inside that class *each* triggered a SwitchPoint invalid
I'm still of the opinion that you shouldn't fix it, or at least
shouldn't demote "noisy" call sites to never optimize. It's not
common, but there are Ruby programs that may define a new class or
method at runtime even at steady state. Not for every request, but
occasionally. I don't like the though
If the bugger here is a repeatedly invalidated SwitchPoint then we (reads: I)
should fix:
7087838: JSR 292: add throttling logic for optimistic call site optimizations
I just don't have a good frequency-based logic yet...
-- Chris
On Dec 1, 2011, at 10:55 PM, Charles Oliver Nutter wrote:
> Pe
On Nov 30, 2011, at 11:37 AM, Lukas Stadler wrote:
> On 2011-11-30 11:20, Charles Oliver Nutter wrote:
>> On Wed, Nov 30, 2011 at 4:17 AM, Lukas Stadler wrote:
>>> Hm, maybe... the fix was really just a tiny tiny bugfix, so that
>>> shouldn't have caused any performance regressions, although, of
On Dec 8, 2011, at 6:58 PM, Charles Oliver Nutter wrote:
> I just had a report of the same error in 1.7.0GA, and I saw it on the
> CI server last night after I set up a 1.7.0_01 build. Did it linger
> into GA?
We have (at least) one known bug with each early-adopter runtime which is not
fixed y
