RFR (S): 8153439: do not install an empty SpeculationLog in an nmethod

Christian Thalinger christian.thalinger at oracle.com
Tue Apr 5 23:52:57 UTC 2016


> On Apr 5, 2016, at 4:16 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
>> 
>> On 05 Apr 2016, at 02:00, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>> 
>>> On Apr 4, 2016, at 12:34 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>>> 
>>> No, not good.  We are failing a couple JVMCI tests.  Looking into it…
>> 
>> Ok, this got a little out of control but for the better:
>> 
>> http://cr.openjdk.java.net/~twisti/8153439/webrev.01/
>> 
>> The actual fix is to check for a null log argument.  The rest is moving the tests into an mx-controlled directory so we can edit and run the tests in an IDE.  This made it much easier to figure out what the issue was because stupid jtreg just swallowed all exceptions.
>> 
>> While moving the tests I fixed a bunch of them because they didn’t have the proper @compile directives and so failed when running standalone.  Again, stupid jtreg.
>> 
>> Also, I’m wondering if hasSpeculations() should be an interface method in SpeculationLog.  I think it should.
> 
> I agree. Can you modify your derivative webrev for that? Of course, we wouldn’t need the cast to HotSpotSpeculationLog in HotSpotCodeCacheProvider once you’ve made that change.

Sure.  Here is the new webrev:

http://cr.openjdk.java.net/~twisti/8153439/webrev.02/

> 
> -Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160405/a49dfc1a/attachment.html>


More information about the hotspot-compiler-dev mailing list