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 Thu, 07 Dec 2006 20:47:45 GMT

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 

> 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.


View raw message