RFR: JDK-8013225: Refresh jdk's private ASM to the latest.

Noel Poore noel.poore at oracle.com
Fri Apr 26 15:30:52 UTC 2013


Brian

For any individual case, there is always an argument that "adding a couple of extra classes won't matter", but if that is the answer to every question, the result is something slow and bloated. Also, what frequently happens is that hardware advances are used to deliver lower cost rather than better performance. I don't know enough to comment on this specific issue, but IMO we should be careful not to just say that "hardware has changed, so these things no longer matter." I could go on at some length about this subject, but don't have time to write a long email right now, so I'll stop here.

Noel

On Apr 26, 2013, at 11:16 AM, Brian Goetz wrote:

> How many years ago was this done?  Hasn't the hardware reality changed since then?  What might have been a justifiable crime then may just be a crime now.  
> 
> On Apr 26, 2013, at 10:12 AM, Paul Sandoz wrote:
> 
>> 
>> On Apr 26, 2013, at 3:25 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>>> On 04/26/2013 01:43 PM, Paul Sandoz wrote:
>>>> On Apr 26, 2013, at 1:26 AM, Kumar Srinivasan <kumar.x.srinivasan at oracle.COM> wrote:
>>>>> On 4/25/2013 3:53 PM, Mike Duigou wrote:
>>>>>> The restyling changes obfustucated things a bit but I didn't see anything of concern in casual review.
>>>>>> 
>>>>>> I had hoped to see the updated SmallSet that didn't try to implement Iterator directly.
>>>>> Remi, Paul and Brian discussed that and struck a deal, maybe Paul/Brain
>>>>> can shed some light on that.
>>>>> 
>>>> If we had stayed with the method names Iterator.forEach and Iterable.forEach (the former was renamed to Iterator.forEachRemaining) then that would have forced a change to SmallSet to fix its rampant layering violation. I don't recall we struck a deal to fix it, but it would be nice if we could do so.
>>> 
>>> The"rampant layering violation" was introduced consciously.
>>> ASM is still used on small devices to re-transform bytecodes at runtime (ASM was originally created for that)
>>> so the core of ASM tries to minimize its memory impact, hence use tricks to avoid to create more classes than it should.
>>> 
>> 
>> Is it really so terribly constrained that there is no room for another class?
>> 
>> Out of curiosity how much does the static memory footprint increase by if you add an additional class implementing an Iterator over 0, 1, or 2 elements?
>> 
>> Paul.
> 




More information about the core-libs-dev mailing list