> Our code is littered with API's that take, or manifest, a Thread* and then
> assert/guarantee that it must be a JavaThread, rather than taking/manifesting
> a JavaThread in the first place. The main reason for this is that the TRAPS
> macro, used in relation to exception generation and process
Thanks for the review Ioi!
David
On 14/05/2021 3:03 am, Ioi Lam wrote:
On Thu, 13 May 2021 04:59:11 GMT, David Holmes wrote:
Our code is littered with API's that take, or manifest, a Thread* and then assert/guarantee that it
must be a JavaThread, rather than taking/manifesting a JavaThread
On Thu, 13 May 2021 04:59:11 GMT, David Holmes wrote:
>> Our code is littered with API's that take, or manifest, a Thread* and then
>> assert/guarantee that it must be a JavaThread, rather than
>> taking/manifesting a JavaThread in the first place. The main reason for this
>> is that the TRAPS
On Thu, 13 May 2021 03:26:50 GMT, Vladimir Kozlov wrote:
> Compiler related changes seems fine.
> @dougxc, note that jvmci is affected. It looks reasonable for me but you may
> need to check if it is correct from libgraal POV.
I tried to test this patch against GraalVM but am blocked due to
`j
> Our code is littered with API's that take, or manifest, a Thread* and then
> assert/guarantee that it must be a JavaThread, rather than taking/manifesting
> a JavaThread in the first place. The main reason for this is that the TRAPS
> macro, used in relation to exception generation and process
On 13/05/2021 1:29 pm, Vladimir Kozlov wrote:
On Tue, 11 May 2021 01:56:21 GMT, David Holmes wrote:
David Holmes has updated the pull request incrementally with one additional
commit since the last revision:
Review feedback from Serguei
Compiler related changes seems fine.
@dougxc, not
On Tue, 11 May 2021 01:56:21 GMT, David Holmes wrote:
>> Our code is littered with API's that take, or manifest, a Thread* and then
>> assert/guarantee that it must be a JavaThread, rather than
>> taking/manifesting a JavaThread in the first place. The main reason for this
>> is that the TRAPS
On Tue, 11 May 2021 01:56:21 GMT, David Holmes wrote:
>> Our code is littered with API's that take, or manifest, a Thread* and then
>> assert/guarantee that it must be a JavaThread, rather than
>> taking/manifesting a JavaThread in the first place. The main reason for this
>> is that the TRAPS
On 11/05/2021 9:00 am, Serguei Spitsyn wrote:
On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote:
src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.cpp line 108:
106:
107: // caller needs ResourceMark
108: const char* get_java_thread_name(const JavaThread* t) {
Nit: Better to
> Our code is littered with API's that take, or manifest, a Thread* and then
> assert/guarantee that it must be a JavaThread, rather than taking/manifesting
> a JavaThread in the first place. The main reason for this is that the TRAPS
> macro, used in relation to exception generation and process
On 11/05/2021 9:14 am, Serguei Spitsyn wrote:
On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote:
David,
This looks pretty good. At least, I do not see real problems.
It is really nice to make it more consistent.
Thanks,
Serguei
Thanks for the review Serguei!
David
-
Marked a
On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote:
> Our code is littered with API's that take, or manifest, a Thread* and then
> assert/guarantee that it must be a JavaThread, rather than taking/manifesting
> a JavaThread in the first place. The main reason for this is that the TRAPS
> macr
On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote:
> Our code is littered with API's that take, or manifest, a Thread* and then
> assert/guarantee that it must be a JavaThread, rather than taking/manifesting
> a JavaThread in the first place. The main reason for this is that the TRAPS
> macr
On Sun, 9 May 2021 22:42:26 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/sharedRuntime.cpp line 1197:
>>
>>> 1195:
>>> 1196: methodHandle SharedRuntime::find_callee_method(TRAPS) {
>>> 1197: JavaThread* current = THREAD;
>>
>> I think these look strange, especially the ones
>> JavaT
On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote:
> Our code is littered with API's that take, or manifest, a Thread* and then
> assert/guarantee that it must be a JavaThread, rather than taking/manifesting
> a JavaThread in the first place. The main reason for this is that the TRAPS
> macr
On Sat, 8 May 2021 13:06:01 GMT, Coleen Phillimore wrote:
>> Our code is littered with API's that take, or manifest, a Thread* and then
>> assert/guarantee that it must be a JavaThread, rather than
>> taking/manifesting a JavaThread in the first place. The main reason for this
>> is that the T
On Wed, 5 May 2021 10:16:29 GMT, David Holmes wrote:
> Our code is littered with API's that take, or manifest, a Thread* and then
> assert/guarantee that it must be a JavaThread, rather than taking/manifesting
> a JavaThread in the first place. The main reason for this is that the TRAPS
> macr
17 matches
Mail list logo
