Hi Ben,
thanks for the information. I have just run an application with these
parameters (and played with some using the link you added). But I
don't get the actual assembler generated (or I can't recognise it); I
do get a lot of output however.
I would expect a lot of i386+ assembler statements (I have done some
assembler many many years ago).
This is a fragment:
OopMap{ebp=Oop [256]=Oop [40]=Oop [44]=Oop [48]=Oop [56]=Oop [96]=Oop
[124]=Oop [128]=Oop [180]=Oop [216]=Oop off=31380}
#442
OopMap{ebp=Oop [256]=Oop [40]=Oop [44]=Oop [48]=Oop [56]=Oop [96]=Oop
[124]=Oop [128]=Oop [180]=Oop [216]=Oop off=31396}
#443
OopMap{ebp=Oop [256]=Oop [40]=Oop [44]=Oop [48]=Oop [56]=Oop [96]=Oop
[124]=Oop [128]=Oop [180]=Oop [216]=Oop off=31412}
#444
OopMap{ebp=Oop [256]=Oop [40]=Oop [44]=Oop [48]=Oop [56]=Oop [96]=Oop
[124]=Oop [128]=Oop [180]=Oop [216]=Oop off=31428}
#445
OopMap{[256]=Oop [24]=Oop [40]=Oop [44]=Oop [48]=Oop [56]=Oop [96]=Oop
[124]=Oop [128]=Oop [180]=Oop [216]=Oop off=31444}
#446
OopMap{off=31460}
#447
OopMap{off=31476}
#448
OopMap{off=31492}
#449
OopMap{off=31508}
#450
OopMap{off=31524}
#451
OopMap{off=31540}
#452
OopMap{off=31556}
#453
OopMap{off=31572}
#454
OopMap{off=31588}
#455
OopMap{off=31604}
#456
OopMap{off=31620}
#457
OopMap{off=31636}
#458
OopMap{off=31652}
#459
OopMap{[256]=Oop [40]=Oop [44]=Oop [48]=Oop [96]=Oop [112]=Oop
[132]=Oop [156]=Oop [176]=Oop [180]=Oop [216]=Oop off=31668}
#460
OopMap{off=31684}
#461
OopMap{off=31700}
#462
OopMap{off=31716}
#463
OopMap{off=31732}
#464
OopMap{off=31748}
#465
OopMap{off=31764}
#466
OopMap{off=31780}
#467
OopMap{off=31796}
#468
OopMap{off=31812}
#469
OopMap{off=31828}
#470
OopMap{off=31844}
#471
OopMap{off=31868}
#472
OopMap{off=31892}
#473
OopMap{[256]=Oop [24]=Oop [40]=Oop [44]=Oop [48]=Oop [92]=Oop
[216]=Oop off=31908}
#474
OopMap{off=31932}
#475
OopMap{off=31948}
#476
OopMap{off=31964}
#477
OopMap{off=31980}
#478
OopMap{off=31996}
#479
OopMap{off=32012}
#480
OopMap{off=32028}
#481
OopMap{off=32044}
#482
OopMap{off=32060}
#483
OopMap{off=32076}
#484
OopMap{off=32096}
#485
OopMap{off=32116}
#486
OopMap{off=32132}
#487
OopMap{[52]=Oop [72]=Oop [108]=Oop [148]=Oop off=32148}
#488
OopMap{off=32164}
#489
OopMap{off=32180}
#490
OopMap{off=32196}
#491
OopMap{off=32212}
#492
OopMap{off=32228}
#493
OopMap{off=32244}
#494
OopMap{off=32260}
#495
OopMap{off=32276}
#496
OopMap{off=32292}
#497
OopMap{off=32308}
#498
OopMap{off=32324}
#499
OopMap{off=32340}
#500
OopMap{off=32356}
Compiled (c2) 82 nmethod (2)
org.multiverse.stms.AbstractTransaction::getStatus (30 bytes)
total in heap [0xb3ab7a88,0xb3ab7bf8] = 368
relocation [0xb3ab7b3c,0xb3ab7b54] = 24
main code [0xb3ab7b60,0xb3ab7bc0] = 96
stub code [0xb3ab7bc0,0xb3ab7bcf] = 15
constants [0xb3ab7bcf,0xb3ab7bd0] = 1
scopes data [0xb3ab7bd0,0xb3ab7bd4] = 4
scopes pcs [0xb3ab7bd4,0xb3ab7bec] = 24
dependencies [0xb3ab7bec,0xb3ab7bf0] = 4
oops [0xb3ab7bf0,0xb3ab7bf8] = 8
OopMapSet contains 0 OopMaps
Compiled (c2) 83 nmethod (2)
java.util.Formatter$FormatSpecifier::checkBadFlags (39 bytes)
total in heap [0xb3ac12c8,0xb3ac15d4] = 780
relocation [0xb3ac137c,0xb3ac13ac] = 48
main code [0xb3ac13c0,0xb3ac14c0] = 256
stub code [0xb3ac14c0,0xb3ac14d9] = 25
constants [0xb3ac14d9,0xb3ac14dc] = 3
scopes data [0xb3ac14dc,0xb3ac1540] = 100
scopes pcs [0xb3ac1540,0xb3ac1594] = 84
dependencies [0xb3ac1594,0xb3ac159c] = 8
handler table [0xb3ac159c,0xb3ac15b4] = 24
nul chk table [0xb3ac15b4,0xb3ac15c8] = 20
On Tue, Dec 15, 2009 at 5:13 PM, Ben Evans
<[email protected]> wrote:
> Hi Peter,
>
> Try a combination like -XX:+UnlockDiagnosticVMOptions
> -XX:+PrintNMethods -XX:+PrintSignatureHandlers -XX:+PrintAssembly
>
> Or this link:
>
> http://wikis.sun.com/display/HotSpotInternals/PrintAssembly
>
> This should work on 6u18 and above.
>
> Thanks,
>
> Ben
>
> On 15 Dec 2009, at 12:31, Peter Veentjer <[email protected]> wrote:
>
>> I also have troubles figuring out how 'smart' the JIT is (or how smart
>> the CPU is).
>>
>> So getting access to the generated assembler would be a big step
>> forward for me as well.
>>
>> ps:
>> although I'm not working on a language, I'm working on a library
>> (http://multiverse.googlecode.com)
>> that could be seen as a language feature (software transactional
>> memory).
>>
>> On Tue, Dec 15, 2009 at 1:09 PM, Kresten Krab Thorup
>> <[email protected]> wrote:
>>> How do you get the emitted code? I did not know you can do that.
>>> Can
>>> you get description of what is inlined and why also?
>>>
>>> On Dec 14, 7:16 pm, Charles Oliver Nutter <[email protected]>
>>> wrote:
>>>> Debug it or just read it? There are numerous options available to
>>>> get
>>>> you assembly output, if that's what you want. I've read more of it
>>>> than I like to admit...
>>>>
>>>> - Charlie
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google
>>> Groups "JVM Languages" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected]
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/jvm-languages?hl=en
>>> .
>>>
>>>
>>>
>>
>> --
>>
>> You received this message because you are subscribed to the Google
>> Groups "JVM Languages" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jvm-languages?hl=en
>> .
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "JVM Languages" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/jvm-languages?hl=en.
>
>
>
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
