2009/12/23 David T. Lewis <lewis at mail.msen.com>:
> On Wed, Dec 23, 2009 at 10:27:42AM -0800, Eliot Miranda wrote:
>> On Wed, Dec 23, 2009 at 6:43 AM, David T. Lewis <lewis at mail.msen.com> wrote:
>>
>> > On Wed, Dec 23, 2009 at 10:27:29AM +0200, Igor Stasenko wrote:
>> > > 2009/12/23 David T. Lewis <lewis at mail.msen.com>:
>> > > > On Tue, Dec 22, 2009 at 01:59:34PM +0100, Andreas Raab wrote:
>> > > >> Folks -
>> > > >>
>> > > >> We're all clear now after the CompiledMethodTrailer changes.
>> > > >> Can I have a 2GB changes file now? And a pony? :)
>> > > >>
>> > > >
>> > > > Here's the 2GB changes file patch. File it in, run tests, install
>> > > > with ExpandedSourceFileArray install.
>> > > >
>> > >
>> > > so, we're now bound to VM file-size handling limitation, or its using
>> > > 64-bits for file pointers?
>> > > 2GB is better than 32M.. but still small :)
>> > >
>> >
>> > Now that CompiledMethod can address unlimited address space, all
>> > that was required was to is to implement three small methods in
>> > a subclass of SourceFileArray (*). So if somebody invents a file
>> > system that maps to all the particles in the universe, we can
>> > easily expand the changes file to make use if it. And as you point
>> > out in another message, it should now be easier to map to things
>> > that are not traditional file systems at all, which does open up
>> > some interesting possibilities.
>> >
>>
>> I'm not up-to-date with the changes.  Are you making sure that the new
>> source manager includes read-only copies of the source files so that
>> fetching source does not involve creating a new file?
>
> The class that I posted affects only the address mapping and would
> not affect any other aspects of source file mapping.
>
> That said, performance is poor so this is not ready for prime time.
> I'm attaching an update that is somewhat less bad, but still nowhere
> near good enough (3 or 4 times slower than StandardSourceFileArray).
>

Dave, i think this is too minor case to care about. Using/computing
sourcePointer usually leads to file operation(s),
which completely nivelating the difference comparing to
StandardSourceFileArray, because file operations working at really
different performance scale (100 to 1000 times slower than any integer
arithmetics) :)


> I will not put this in the inbox until performance is at a more
> reasonable level.  Help from the more capable bit twiddlers is
> welcome (need a more efficient way to test an integer for bit
> 25 set).
>

its easy to tweak it using bit-shifts & bit-masks only (to avoid division).
But since results will be the same, i wouldn't pay much attention to it.


> Dave
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.