[Vm-dev] [Fwd: Image file loading]
Andreas Raab
andreas.raab at gmx.de
Wed Jan 20 18:01:30 UTC 2010
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.
Cheers,
- Andreas
More information about the Vm-dev
mailing list