harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <alex.blew...@gmail.com>
Subject Re: [classlib][pack200] Using ASM instead of BCEL in pack200
Date Mon, 22 Sep 2008 15:58:17 GMT
Ah, right - yeah, for reading in it doesn't make a difference, since  
once it is in memory it gets reordered gratuitously anyway. I think  
the Sun alto preserves order that the constants are seen in the  
original bytecode, but as long as decompressor provides stable results  
then it shouldn't matter.

I think the reason the cp pool ordering is so anal when writing is to  
allow constant offsets to be represented by an incremental integer in  
the pack file.

So for reading, no, it shouldn't matter. Sorry for the objection.

Alex

Sent from my (new) iPhone

On 22 Sep 2008, at 16:11, "Sian January" <sianjanuary@googlemail.com>  
wrote:

> I know there is a very specific ordering, but I don't think it's
> related to the ordering in the original file is it?  I'm only using
> ASM to read in class files for the compressor (i.e. pack200 rather
> than unpack200) as we've already written our own class-file writer for
> unpack200.  I'm pretty sure the constants should be sorted in
> something like alphabetical order for packing.  Is that wrong?
>
> 2008/9/22 Alex Blewitt <alex.blewitt@gmail.com>:
>> There absolutely will be problems if you don't have access to the  
>> constant
>> pool. You need to ensure a very specific ordering of all bytecode and
>> constant pools to be compatible with pack200 - that's why ASM  
>> wasn't used in
>> the first place.
>>
>> Alex
>>
>> Sent from my (new) iPhone
>>
>> On 22 Sep 2008, at 11:46, "Sian January"  
>> <sianjanuary@googlemail.com> wrote:
>>
>>> In the last week I've finally had some time to look at replacing  
>>> BCEL
>>> with ASM in pack200.  I preferred ASM over SERP or any other options
>>> mainly because it is really small (43K) and also has good  
>>> performance.
>>> So I've done some prototyping work and I'm fairly confident ASM is
>>> suitable, although there could potentially be future problems with  
>>> the
>>> fact that ASM doesn't give access to the constant pool itself and  
>>> just
>>> inlines the constants, so I've tried to write my code in a way that
>>> means it wouldn't be too hard to replace it if more functionality  
>>> was
>>> needed at some point.
>>>
>>> So I'm planning to check in my initial work this week if no-one has
>>> any objections.  As we're not using ASM anywhere else at the  
>>> moment is
>>> it ok to just check the jar file in under the pack200 directory, or
>>> should it be in the depends directory and have a manifest  
>>> instead?  Is
>>> there anything else I need to do for bringing in BSD licensed code,
>>> e.g. any notices or license files or source that also need to be
>>> added?
>>>
>>> Thanks,
>>>
>>> Sian
>>>
>>>
>>> --
>>> Unless stated otherwise above:
>>> IBM United Kingdom Limited - Registered in England and Wales with  
>>> number
>>> 741598.
>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire  
>>> PO6 3AU
>>
>
>
>
> -- 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with  
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire  
> PO6 3AU

Mime
View raw message