harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [jira] Commented: (HARMONY-2130) DaCapo antlr fails on drlvm
Date Fri, 08 Dec 2006 15:19:48 GMT

Nathan Beyer wrote:
> On 12/7/06, Stefano Mazzocchi <stefano@apache.org> wrote:
>> Vladimir Strigun (JIRA) wrote:
>> >     [ 
>> http://issues.apache.org/jira/browse/HARMONY-2130?page=comments#action_12456467 
>> ]
>> >
>> > Vladimir Strigun commented on HARMONY-2130:
>> > -------------------------------------------
>> >
>> > Robin,
>> >
>> > Unfortunately I can't say that I agree with you. Yes, antlr 
>> benchmark works correctly on more that 8 VMs, but the reason that 
>> benchmark finished abnormal on DRLVM is antl.jar in bootclasspath of 
>> VM. So, if I correctly understand the behavior of the bench will be 
>> the same on other VM's with antlr.jar bootclasspathed. As far as I can 
>> see from build file of Dacapo, you download antlr sources, patch it 
>> (the main point here is removing of System.exit() call from main 
>> method of Tool class), build it and use run Tool class during 
>> benchmarking.
>> > I've suggested to add additional method to AntlrHarness class that 
>> allows to avoid usage of main() function. In that case benchmark 
>> passes on VM with antlr bootclasspathed. Of course, version check 
>> should be done prior to execution.
>> >
>> > What do you think about it?
>> I'm sorry, but this argument is defective.
>> Sun does ship xerces and xalan bootclasspathed and to avoid
>> interference, they moved the packages.
> Sun may do this, but IBM doesn't. I don't know about Java 5 distros,
> but with IBM Java 1.4.2 JREs, the xerces and xalan classes weren't
> changed and do cause interference.

That's insane.


> -Nathan
>> If we provide something that our own internal machinery depends on, we
>> either shield it and avoids it showing in the userland classloading
>> area, or we change the package and make it 'our own' stuff.
>> Asking any program to adapt to our own behavior (whatever that is and
>> for whatever technical reason) is wrong and against basic
>> interoperability principles.
>> *any* program that runs on RI should run, unmodified, on harmony.
>> Anything else is a bug and needs to be fixed, somehow.
>> So, we can be clever and write a classloader that understands who is
>> calling and provides 'virtual' classloading zones (but I'm not sure this
>> can be made compatible with the java spec) or we bytecode-rewire the
>> packages of the libraries we bootclasspath.
>> Asking others to change is not an option.
>> -- 
>> Stefano.

View raw message