Gregory Shimansky wrote:
On Thursday 14 September 2006 09:29 Geir Magnusson Jr. wrote:
Gregory Shimansky wrote:
Actually this problematic function is used only in GetThreadGroupChildren
for the information about threads and thread groups contained inside of
this thread group. If this informat
On Thursday 14 September 2006 09:15 Alexey Varlamov wrote:
> > A more problematic data in my view may be something like
> > Thread.getContextClassLoader(). Since it is not directly needed for
> > threading model it isn't probably kept in any native structures. Getting
> > it may be done through dir
On Thursday 14 September 2006 09:29 Geir Magnusson Jr. wrote:
> Gregory Shimansky wrote:
> > Actually this problematic function is used only in GetThreadGroupChildren
> > for the information about threads and thread groups contained inside of
> > this thread group. If this information is available
Rana Dasgupta wrote:
Weldon,
It may be a little early to guard for architectural impact of large parts
of the VM being written in Java? I don't think that we are quite there yet
or need to consciously design to enable this till we have completed the
MMTk
integration and done exhaustive perf
Gregory Shimansky wrote:
On Wednesday 13 September 2006 09:19 Alexey Varlamov wrote:
The Thread.getContextClassLoader() just performs access restriction
checks and return the corresponding field value.
I think the only problematic function is ThreadGroup.enumerate() -
unless security access co
14.09.06, Gregory Shimansky<[EMAIL PROTECTED]> написал(а):
On Wednesday 13 September 2006 16:14 Weldon Washburn wrote:
> Gregory,
>
> You might want to look closely at the code paths in the JVMTI functions.
> If the functions in question happen to be arbitrary Java code, then these
> code paths c
Weldon,
It may be a little early to guard for architectural impact of large parts
of the VM being written in Java? I don't think that we are quite there yet
or need to consciously design to enable this till we have completed the MMTk
integration and done exhaustive perf work.
In addition to th
On Wednesday 13 September 2006 16:14 Weldon Washburn wrote:
> Gregory,
>
> You might want to look closely at the code paths in the JVMTI functions.
> If the functions in question happen to be arbitrary Java code, then these
> code paths could lead to many other parts of the JVM which in turn might
On Wednesday 13 September 2006 09:19 Alexey Varlamov wrote:
> The Thread.getContextClassLoader() just performs access restriction
> checks and return the corresponding field value.
> I think the only problematic function is ThreadGroup.enumerate() -
> unless security access control is applicable to
Gregory,
You might want to look closely at the code paths in the JVMTI functions. If
the functions in question happen to be arbitrary Java code, then these code
paths could lead to many other parts of the JVM which in turn might be
written in Java. In the future the JIT runtime helpers or the G
On 9/13/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote:
Gregory Shimansky wrote:
> Hello
>
> I have recently identified a problem which may potentially lead to an infinite
> recursion with the current implementation of some JVMTI functions in DRLVM.
> The functions like GetThreadInfo or GetThreadGr
2006/9/13, Gregory Shimansky <[EMAIL PROTECTED]>:
Hello
I have recently identified a problem which may potentially lead to an infinite
recursion with the current implementation of some JVMTI functions in DRLVM.
The functions like GetThreadInfo or GetThreadGroupInfo call Java methods like
Thread.
Gregory Shimansky wrote:
Hello
I have recently identified a problem which may potentially lead to an infinite
recursion with the current implementation of some JVMTI functions in DRLVM.
The functions like GetThreadInfo or GetThreadGroupInfo call Java methods like
Thread.getName() to return th
It might be OK to disable the event notification on loopback for these
thread/threadgroup java methods only? Would the misses of notification for
such methods in CompiledMethodLoad be a major issue?
Thanks,
Rana
Hello
I have recently identified a problem which may potentially lead to an infinite
recursion with the current implementation of some JVMTI functions in DRLVM.
The functions like GetThreadInfo or GetThreadGroupInfo call Java methods like
Thread.getName() to return the necessary information to
15 matches
Mail list logo
