lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <dawid.we...@cs.put.poznan.pl>
Subject Re: [JENKINS] Lucene-Solr-4.x-Linux-Java6-64 - Build # 101 - Failure!
Date Thu, 14 Jun 2012 08:16:07 GMT
> It certainly wouldn't be easy to do ... but it sure would it be nice :)

I meant "difficult" as in "practically impossible" :) But then so are
these -- http://js1k.com/

>> There's been some talk about tools to detect data races at the hotspot

Found it -- see this thread:
http://cs.oswego.edu/pipermail/concurrency-interest/2011-September/008205.html

The tool I briefly looked at was this one:
http://babelfish.arc.nasa.gov/trac/jpf

> Or, even, just a way to record and then visualize what the thread
> scheduling had been for a given test failure.  In this case I could
> have easily seen that a merge had completed before the NRT reader was
> pulled (which is... unusual).

This is in fact relatively easy if we allowed a jenkins run with some
minor boot classpath adjustments overriding Thread's init/exit methods
and logging timings from there. Obviously it'd have to be bound to a
particular jvm version/ distribution but it can be done. Bytecode
instrumentation would be a nicer alternative here but I'm not sure how
deep it can go in terms of precedence (it'd probably need to be a
native agent and this seems like an overkill).

I also think (didn't check) YourKit's profiler has a thread schedule
visualizer but this adds additional overhead and requires a gui (or
remoting).

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message