[#1207] warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...>

This message was posted to ruby-talk, but I didn't get responce from

22 messages 2003/07/01
[#1208] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/01

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1209] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/02

ts wrote:

[#1210] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/02

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1211] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/04

ts wrote:

[#1212] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/04

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1213] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/04

ts wrote:

[#1214] Re: warning in ruby extension eats memory — ts <decoux@...> 2003/07/04

>>>>> "E" == Eugene Scripnik <Eugene.Scripnik@itgrp.net> writes:

[#1215] Re: warning in ruby extension eats memory — Eugene Scripnik <Eugene.Scripnik@...> 2003/07/04

ts wrote:

[#1237] FTP.new with block — Gavin Sinclair <gsinclair@...>

Hi,

22 messages 2003/07/19
[#1238] Re: [Patch] FTP.new with block — ts <decoux@...> 2003/07/19

>>>>> "G" == Gavin Sinclair <gsinclair@soyabean.com.au> writes:

[#1240] Re: [Patch] FTP.new with block — Mathieu Bouchard <matju@...> 2003/07/19

[#1297] Fix for Bug 1058 — Markus Walser <walser@...>

Hi,

16 messages 2003/07/25

Re: stack problem

From: nobu.nokada@...
Date: 2003-07-23 02:08:00 UTC
List: ruby-core #1283
Hi,

At Wed, 23 Jul 2003 10:47:03 +0900,
Mathieu Bouchard wrote:
> > > I don't know what makes you think that rounding by pagesize might be
> > > better: it is not quite obvious to me. So I would enjoy an explanation.
> > Just it would be faster.  No matter.
> 
> Ok, for the speed improvement, I'm not convinced, unless someone finds a
> way to be forced to call ruby_init after a multi-megabyte ALLOCA, but I
> can't see that ever taking more than a few millisecs.

Agree.  It's just a thought.

> Next, my concern is this:
> 
>   volatile char *p = bp - size;
>   (void)*p;
> 
> Is this resistant to heavy optimisation? I mean, (void)*p can be reduced
> to nothingness, despite the volatility of the target data. I was writing
> to a volatile dummy variable using the result from the read, to ensure
> that the read was being done.

Such "optimization" should be wrong.  If a volatile variable is
memory mapped I/O, just reading is meaningful.  If a compiler
does reduce it, the compiler has a bug in the optimizer.

> Maybe I don't completely know what "volatile" is supposed to mean (?)

IIRC, all optimization for volatile access must be suppressed.

However, I noticed that there is no check for volatile.  Does
anyone know from when autoconf has AC_C_VOLATILE?

-- 
Nobu Nakada

In This Thread