harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [jira] Commented: (HARMONY-2130) DaCapo antlr fails on drlvm
Date Fri, 08 Dec 2006 02:52:09 GMT
inlined

Geir Magnusson Jr. wrote:
> inline
> 
> Stefano Mazzocchi 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.
>>
>> 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.
> 
> Agreed - we really can't ask people to change.  The fact that Harmony 
> uses something as a dependency shouldn't be something a user cares about 
> - that's the "compatibility promise" of Java.
> 
> That said,  if Robin et al could temporarily work around our bug for 
> now, that would be helpful.  More running benchmark code on Harmony, the 
> better.

I've made a version of the patched antlr.jar available on my personal 
web page - longer term, in the next maintenance release of DaCapo, I 
will add a target to the build.xml to produce a standalone antlr.jar 
that people can prepend to the boot classpath.

   http://cs.anu.edu.au/people/Robin.Garner/dacapo/antlr-dacapo.jar

This is the approach I'm using to do the dacapo regression tests.

>>
>> 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.
> 
> The bytecode re-wire is one option.  I've pondered how to structure 
> things with some kind of "outer" boot classloader or something that 
> userland code would use, and would delegate everything through to an 
> "inner" loader except for xerces, antlr, bcel, etc - the stuff we use on 
> the boot classpath.
> 
> geir
> 
> 
> 


-- 
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/

Mime
View raw message