[ 
https://issues.apache.org/jira/browse/LUCENE-4711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13560741#comment-13560741
 ] 

Shai Erera commented on LUCENE-4711:
------------------------------------

I reported a bug with the J9 team, let's wait for their response.

In the meanwhile, Gilad and I have investigated it more. Gilad found this link: 
http://www.javaspecialists.eu/archive/Issue179.html, which says "With a small 
test, we see that the varargs also does not create objects on the Java Heap as 
long as the array is small enough". That's weird .. as if the JVM 
implementation can decide to allocate small arrays outside the heap space .. so 
what does it mean? Is it not safe to save a reference to a vararg parameter?

We searched the JLS, but couldn't find anything relevant. Also, we've been able 
to isolate the problem to a small testcase (attached), which reproduces the 
problem quite easily. Interestingly, if we pass many arguments to the varargs 
constructor, the error doesn't happen .. maybe because then the JVM is forced 
to allocate the array on the heap, since it's "large enough".
                
> IBM J9 1.7.0 JIT bug in CategoryPath
> ------------------------------------
>
>                 Key: LUCENE-4711
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4711
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: modules/facet
>            Reporter: Shai Erera
>            Assignee: Shai Erera
>             Fix For: 4.2, 5.0
>
>
> When running facet tests with IBM J9 1.7.0, most of the tests fail with 
> bizarre exceptions from CategoryPath (AIIOBE mostly). I tried to add few 
> asserts to CategoryPath, but they didn't help to reveal the bug.
> Today I ran a single test {{TestAssociationExample}} (randomly picked) w/ 
> -Dtests.iters=1000 and it failed too on the same error. If run w/ -Xint, it 
> doesn't fail.
> In the end, Gilad and I discovered that when {{CategoryPath(String... 
> components)}} constructor is used, which inside does {{this.components = 
> components}}, the bug is triggered. At some point, probably after JIT kicks 
> in, the array's length is 0'ed !!!
> We've added the following workaround to CategoryPath:
> {code}
> // TODO: revisit when IBM releases Java 7 newer than SR3 (with a fix)
> // to validate, run e.g. TestAssociationExample with -Dtests.iters=1000
> private static final boolean IS_J9_JAVA7 = Constants.JRE_IS_MINIMUM_JAVA7 && 
> Constants.JVM_VENDOR.contains("IBM");
> ...
> public CategoryPath(final String... components) {
>   assert components.length > 0 : "use CategoryPath.EMPTY to create an empty 
> path";
>   if (IS_J9_JAVA7) {
>     // On IBM J9 Java 1.7.0, if we do 'this.components = components', then
>     // at some point its length becomes 0 ... quite unexpectedly. If JIT is
>     // disabled, it doesn't happen. This bypasses the bug by copying the 
>     // array (note, Arrays.copyOf did not help either!).
>     this.components = new String[components.length];
>     System.arraycopy(components, 0, this.components, 0, components.length);
>   } else {
>     this.components = components;
>   }
>   length = components.length;
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to