[Vm-dev] [Fwd: Image file loading]

[Igor Stasenko]

2010/1/20 Andreas Raab <andreas.raab at gmx.de>:
>
> Igor Stasenko wrote:
>>>
>>> The platform already completely controls the allocation. It's only that
>>> we
>>> allow the interpreter to make the first request and that request is based
>>> on
>>> what we've passed in as desiredHeapSize from the support code. Lots of
>>> useless complexity, the support code might as well just allocate it
>>> without
>>> involving the interpreter.
>>>
>>
>> Support code may not know the image size beforehead.
>
> Yes it does. The support code does the reading after all. Since an entire
> image file needs to be read before it can be interpreted, there is no way
> that the support code wouldn't know its size. Even if you ship it over the
> wire (say in a http request) all protocols that I'm aware about have
> information that encode the size of its payload (Content-Length in http).
> The fact that the dataLength is also part of the header should be seen as a
> duplication of information that can be used by the interpreter to verify the
> integrity of the image. It doesn't mean that this will be the only source of
> information about the size of the image.
>
>> Or image file could be combined with something else into a single file
>> , which makes it much larger than actually need for image.
>
> If you need that, you would implement the means to recognize and reconcile
> the situation appropriately. For example, on Android I'm not loading the
> entire package into memory. I'm extracting portions of the zip file and load
> them into proper locations. I'm doing this because I'm in a non-standard
> situation that requires adjusting for its tradeoffs.
>
> However, we know that the "standard situation" is one in which loading the
> entire image file is entirely appropriate. Moreoever, we know that
> regardless of the method of I/O we're using we always need to produce a
> complete image file first. Since we know that, and since the method of I/O
> will differ depending on the context in which your VM runs in, it is not
> meaningful to worry about situations that you describe - nobody would load
> more than they'd have to unless that's considered a reasonable tradeoff
> (there may be situations where this is actually advantageous).
>
> There is really nothing to worry about here. The standard situation is that
> we can read an entire image file. The non-standard situations have to be
> dealt with on a case-by-case basis  but in any case they'll have a means of
> identifying the image, loading into memory and providing it to the
> interpreter. There is no reason to worry about someone writing the support
> code just randomly passing excess bytes to the interpreter.
>

Well, i mainly meant some kind of a network startup scenario, when
image data is feeded directly from socket.
Platform code could pass the socket to interpreter (as void* object),
and then wait for allocation & read requests which will follow.
And so, you don't have to use some intermediate memory buffer to
preload an image and only then pass
it to interpreter entry point.

> Cheers,
>  - Andreas
>



-- 
Best regards,
Igor Stasenko AKA sig.