Whoa... never seen this one before --

   [junit4] >>> error stream from forked JVM (verbatim) ----
   [junit4] OpenJDK 64-Bit Server VM warning: CodeCache is full.
Compiler has been disabled.
   [junit4] OpenJDK 64-Bit Server VM warning: Try increasing the code
cache size using -XX:ReservedCodeCacheSize   [junit4] <<< EOF ----

FYI, this doesn't get printed through regular Java's System.* streams
-- it is printed from the JVM internals directly (via original,
un-redirected stream descriptors). <junit4> currently considers
ANYTHING that is printed to these streams as a potential JVM failure
-- I wonder if I should alter this behavior.

On the second thought... this does seem abnormal to me. Thoughts?

Dawid

On Thu, Apr 19, 2012 at 8:42 AM, Apache Jenkins Server
<[EMAIL PROTECTED]> wrote:
> Build: https://builds.apache.org/job/Lucene-trunk/1899/
>
> All tests passed
>
> Build Log (for compile errors):
> [...truncated 26892 lines...]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------

I have seen this on jenkins several times (especially with Clover instrumentation). In this case instrumentation was running.

I think its caused by too many instrumentation (per statement) in heavy tests like TestNRQ or similar. Unfortunately we don’t see here, which test exactly was leading to this output.

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> Dawid Weiss
> Sent: Thursday, April 19, 2012 9:05 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
>
> Whoa... never seen this one before --
>
>    [junit4] >>> error stream from forked JVM (verbatim) ----
>    [junit4] OpenJDK 64-Bit Server VM warning: CodeCache is full.
> Compiler has been disabled.
>    [junit4] OpenJDK 64-Bit Server VM warning: Try increasing the code cache
> size using -XX:ReservedCodeCacheSize>    [junit4] <<< EOF ----
>
> FYI, this doesn't get printed through regular Java's System.* streams
> -- it is printed from the JVM internals directly (via original, un-redirected
> stream descriptors). <junit4> currently considers ANYTHING that is printed to
> these streams as a potential JVM failure
> -- I wonder if I should alter this behavior.
>
> On the second thought... this does seem abnormal to me. Thoughts?
>
> Dawid
>
> On Thu, Apr 19, 2012 at 8:42 AM, Apache Jenkins Server
> <[EMAIL PROTECTED]> wrote:
> > Build: https://builds.apache.org/job/Lucene-trunk/1899/
> >
> > All tests passed
> >
> > Build Log (for compile errors):
> > [...truncated 26892 lines...]
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED] For
> > additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------

> I have seen this on jenkins several times (especially with Clover instrumentation). In this case instrumentation was running.

Clover is a hog, we've experienced that too.

> I think its caused by too many instrumentation (per statement) in heavy tests like TestNRQ or similar. Unfortunately we don’t see here, which test exactly was leading to this output.

I don't think you'd be able to see that precisely anyway because these
are printed to two different stream buffers -- it bypasses Java's
PrintStreams and dumps directly to the original file descriptor.

Dawid

---------------------------------------------------------------------

I'll try to inspect later today why these are so slow in that run:

   [junit4] <JUnit4> says g'day! Master seed: C26BAC36B9BF265D

   [junit4] Suite: org.apache.lucene.index.TestByteSlices
   [junit4] Completed in 1852.84s, 1 test

   [junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64
   [junit4] Completed in 4251.28s, 34 tests

Dawid

On Thu, Apr 19, 2012 at 9:28 AM, Dawid Weiss
<[EMAIL PROTECTED]> wrote:
>> I have seen this on jenkins several times (especially with Clover instrumentation). In this case instrumentation was running.
>
> Clover is a hog, we've experienced that too.
>
>> I think its caused by too many instrumentation (per statement) in heavy tests like TestNRQ or similar. Unfortunately we don’t see here, which test exactly was leading to this output.
>
> I don't think you'd be able to see that precisely anyway because these
> are printed to two different stream buffers -- it bypasses Java's
> PrintStreams and dumps directly to the original file descriptor.
>
> Dawid

---------------------------------------------------------------------

Hi,

Maybe TestNRQ does not like SimpleText (it seeks heavily), so maybe thats the reason (we should check that with the seed) and add assume. Do other MTQ tests allow SimpleText (like Fuzzy, which is also heavy)? With Clover the NRQ tests then gets *very* slow. Compare with TestNRQ32, which succeeded in a few seconds on the same run, just because of different random settings.

Because of the instrumentation level per statement, all tight loops take forever with clover. But changing to "method" level removes all the interesting information for us. We could also add a @NoClover annotation. We would need no sysprops for that, it would be enough to do a Class.forName on any of the clover classes to find out if clover is "active" for the current test run.

Maybe we should raise the JVM setting for the code cache when running with clover, because clover-instrumented class files are a lot more "complex" for hotspot.

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> Dawid Weiss
> Sent: Thursday, April 19, 2012 9:38 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
>
> I'll try to inspect later today why these are so slow in that run:
>
>    [junit4] <JUnit4> says g'day! Master seed: C26BAC36B9BF265D
>
>    [junit4] Suite: org.apache.lucene.index.TestByteSlices
>    [junit4] Completed in 1852.84s, 1 test
>
>    [junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64
>    [junit4] Completed in 4251.28s, 34 tests
>
> Dawid
>
> On Thu, Apr 19, 2012 at 9:28 AM, Dawid Weiss
> <[EMAIL PROTECTED]> wrote:
> >> I have seen this on jenkins several times (especially with Clover
> instrumentation). In this case instrumentation was running.
> >
> > Clover is a hog, we've experienced that too.
> >
> >> I think its caused by too many instrumentation (per statement) in heavy tests
> like TestNRQ or similar. Unfortunately we don’t see here, which test exactly
> was leading to this output.
> >
> > I don't think you'd be able to see that precisely anyway because these
> > are printed to two different stream buffers -- it bypasses Java's
> > PrintStreams and dumps directly to the original file descriptor.
> >
> > Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------

To disable clover for heavy tests, we can use (its just a code comment to be included, that tells the instrumenter to disable coverage for this code part between the comments):

http://goo.gl/ZohAv

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]
> -----Original Message-----
> From: Uwe Schindler [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 19, 2012 9:47 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JENKINS] Lucene-trunk - Build # 1899 - Failure
>
> Hi,
>
> Maybe TestNRQ does not like SimpleText (it seeks heavily), so maybe thats the
> reason (we should check that with the seed) and add assume. Do other MTQ
> tests allow SimpleText (like Fuzzy, which is also heavy)? With Clover the NRQ
> tests then gets *very* slow. Compare with TestNRQ32, which succeeded in a
> few seconds on the same run, just because of different random settings.
>
> Because of the instrumentation level per statement, all tight loops take forever
> with clover. But changing to "method" level removes all the interesting
> information for us. We could also add a @NoClover annotation. We would need
> no sysprops for that, it would be enough to do a Class.forName on any of the
> clover classes to find out if clover is "active" for the current test run.
>
> Maybe we should raise the JVM setting for the code cache when running with
> clover, because clover-instrumented class files are a lot more "complex" for
> hotspot.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: [EMAIL PROTECTED]
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
> > Of Dawid Weiss
> > Sent: Thursday, April 19, 2012 9:38 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
> >
> > I'll try to inspect later today why these are so slow in that run:
> >
> >    [junit4] <JUnit4> says g'day! Master seed: C26BAC36B9BF265D
> >
> >    [junit4] Suite: org.apache.lucene.index.TestByteSlices
> >    [junit4] Completed in 1852.84s, 1 test
> >
> >    [junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64
> >    [junit4] Completed in 4251.28s, 34 tests
> >
> > Dawid
> >
> > On Thu, Apr 19, 2012 at 9:28 AM, Dawid Weiss
> > <[EMAIL PROTECTED]> wrote:
> > >> I have seen this on jenkins several times (especially with Clover
> > instrumentation). In this case instrumentation was running.
> > >
> > > Clover is a hog, we've experienced that too.
> > >
> > >> I think its caused by too many instrumentation (per statement) in
> > >> heavy tests
> > like TestNRQ or similar. Unfortunately we don’t see here, which test
> > exactly was leading to this output.
> > >
> > > I don't think you'd be able to see that precisely anyway because
> > > these are printed to two different stream buffers -- it bypasses
> > > Java's PrintStreams and dumps directly to the original file descriptor.
> > >
> > > Dawid
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED] For
> > additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------

This is probably a better idea as it allows fine-grained control (i.e.
excluding just tight loops)?

Dawid

On Thu, Apr 19, 2012 at 10:15 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> To disable clover for heavy tests, we can use (its just a code comment to be included, that tells the instrumenter to disable coverage for this code part between the comments):
>
> http://goo.gl/ZohAv
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: [EMAIL PROTECTED]
>
>
>> -----Original Message-----
>> From: Uwe Schindler [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, April 19, 2012 9:47 AM
>> To: [EMAIL PROTECTED]
>> Subject: RE: [JENKINS] Lucene-trunk - Build # 1899 - Failure
>>
>> Hi,
>>
>> Maybe TestNRQ does not like SimpleText (it seeks heavily), so maybe thats the
>> reason (we should check that with the seed) and add assume. Do other MTQ
>> tests allow SimpleText (like Fuzzy, which is also heavy)? With Clover the NRQ
>> tests then gets *very* slow. Compare with TestNRQ32, which succeeded in a
>> few seconds on the same run, just because of different random settings.
>>
>> Because of the instrumentation level per statement, all tight loops take forever
>> with clover. But changing to "method" level removes all the interesting
>> information for us. We could also add a @NoClover annotation. We would need
>> no sysprops for that, it would be enough to do a Class.forName on any of the
>> clover classes to find out if clover is "active" for the current test run.
>>
>> Maybe we should raise the JVM setting for the code cache when running with
>> clover, because clover-instrumented class files are a lot more "complex" for
>> hotspot.
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: [EMAIL PROTECTED]
>>
>>
>> > -----Original Message-----
>> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
>> > Of Dawid Weiss
>> > Sent: Thursday, April 19, 2012 9:38 AM
>> > To: [EMAIL PROTECTED]
>> > Subject: Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure
>> >
>> > I'll try to inspect later today why these are so slow in that run:
>> >
>> >    [junit4] <JUnit4> says g'day! Master seed: C26BAC36B9BF265D
>> >
>> >    [junit4] Suite: org.apache.lucene.index.TestByteSlices
>> >    [junit4] Completed in 1852.84s, 1 test
>> >
>> >    [junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64
>> >    [junit4] Completed in 4251.28s, 34 tests
>> >
>> > Dawid
>> >
>> > On Thu, Apr 19, 2012 at 9:28 AM, Dawid Weiss
>> > <[EMAIL PROTECTED]> wrote:
>> > >> I have seen this on jenkins several times (especially with Clover
>> > instrumentation). In this case instrumentation was running.
>> > >
>> > > Clover is a hog, we've experienced that too.
>> > >
>> > >> I think its caused by too many instrumentation (per statement) in
>> > >> heavy tests
>> > like TestNRQ or similar. Unfortunately we don’t see here, which test
>> > exactly was leading to this output.
>> > >
>> > > I don't think you'd be able to see that precisely anyway because
>> > > these are printed to two different stream buffers -- it bypasses
>> > > Java's PrintStreams and dumps directly to the original file descriptor.
>> > >
>> > > Dawid
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED] For
>> > additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
>> commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

---------------------------------------------------------------------