You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Andrey Chernyshev <a....@gmail.com> on 2006/07/04 20:07:42 UTC
[classlib] Is it OK for VM kernel class to call internal classlib API?
I was trying to compile the kernel classes set from DRLVM independently
from the classlib and found it difficult because kernel classes set
currently have a dependence on the internal classlib API, e.g.
org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection
and org.apache.harmony.luni.util.DeleteOnExit classes.
I've found the spec for kernel class org.apache.harmony.kernel.vm.VM
(l'm looking at
classlib\trunk\modules\luni-kernel\src\main\java\org\apache\harmony\kernel\vm\VM.java)
assumes that VM is calling excplicitly JarURLConnection.closeCachedFiles()
and DeleteOnExit.deleteOnExit() during VM shutdown.
On the other hand, there is standard API in J2SE called
java.lang.Runtime.addShutdownHook(Thread) which can be used to specify
the
tasks that have to be done during VM shutdown.
BTW, this is exactly how DRLVM implements these methods in it's
VM.java. For example, for VM.closeJars() it currently does like:
public static void closeJars() {
class CloseJarsHook implements Runnable {
public void run() {
JarURLConnection.closeCachedFiles();
}
}
...
Runtime.getRuntime().addShutdownHook(new Thread(new CloseJarsHook()));
}
Are there any problems with this approach, should the DRLVM (or other
Vm's) implement these methods differently?
May be it makes sense just to move VM.closeJars() and
VM.deleteOnExit() methods and their drlvm implementation to the luni
classlib component, under assumption that they do not really contain
any VM-specific code?
I guess it will simplify a bit the org.apache.harmony.kernel.vm.VM
interface as well as would allow to avoid extra dependencies between
VM and classlib.
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Is it OK for VM kernel class to call internal classlib
API?
Posted by Oliver Deakin <ol...@googlemail.com>.
Andrey Chernyshev wrote:
> On 7/10/06, Oliver Deakin <ol...@googlemail.com> wrote:
>> Andrey Chernyshev wrote:
>> <snip>
>> >
>> > Thanks Oliver, this explanation sounds reasonable.
>> > If the issue is just in the shutdown hooks order, then, still may be
>> > it makes sense to add VM.addClasslibShutdownHook(Runnable) method or
>> > something like that, which can be:
>> > - used by the classlib to do whatever resource cleanup / shutdown
>> > works they need;
>> > - guaranteed by VM to be executed always after Runtime's shutdown
>> > hooks are done (can be specified in the contract)?
>> > This approach looks more universal than having two specific methods
>> > cloaseJars() and deletOnExit(). It will also allow VM to do not call
>> > internal classlib API explicitly.
>>
>> I think the same problem exists with this approach. You still need to
>> guarantee that closeCachedFiles() and deleteOnExit() are the last
>> classlib
>> shutdown hooks that are called, otherwise they may cause problems
>
> I think class lib could add just one shutdown hook which is guaranteed
> by VM to be run after all other (e.g. application's) shutdown hooks
> are completed.
How will the VM know which shutdown hook is the right one?
> Within this shutdown hook, classlib are free to choose whatever order
> they like, e.g. run all others hooks (whatever may appear in classlib
> in the future) and then finally call closeCachedFiles() and
> deleteOnExit().
>
> My point was that, if classlib do really care about the shutdown
> sequence of it's internal resources, it should be classlib who defines
> the shutdown hooks execution order, not VM. IMHO there is no need to
> bring this up to the classlib<->VM contract.
Isn't adding a special shutdown hook that the classlib requires and
the VM runs last another classlib<->VM contract?
>
>> with any classlib shutdown hooks called after them. Once you put
>> a restriction on the classlib shutdown hooks that closeCachedFiles() and
>> deleteOnExit() will be that last ones called, you are basically
>> in a similar situation to just calling the methods explicitly after all
>> shutdown hooks complete.
>
> I agree the situation is exactly the same in terms of the code being
> executed, the only question is where this code is located - VM.java
> (which is a part of VM, right?) or classlib. I think the good
> interface between VM and classlib would minimize VM's knowledge about
> classlib and vice versa. In the ideal situation, I would limit it to a
> subset of J2SE API.
But remember that the kernel classes are the Java part of the interface
between
the VM and classlib, not wholly a part of the VM. They are implemented
by the
VM vendor because they require internal knowledge of the VM (or vice versa)
- this does not mean that they cannot have internal knowledge of the class
libraries also.
>
>>
>> I think it would be fine to add an addClasslibShutdownHook() method
>> to VM if it was needed, but at the moment I don't believe it is. You are
>
> well, to be precise, I'm suggesting to replace existing VM.closeJars()
> and VM.deletOnExit() with VM.addClasslibShutdownHook(), not just to
> add :)
>
>> always going to be in the position of requiring closeCachedFiles()
>> and deleteOnExit() to run last, and adding an extra shutdown hook
>> mechanism will not change that.
>
> I thought of:
> - VM could guarantee that the classlib shutdown hook is run last;
> - Classlib could guarantee that closeCachedFiles() and deleteOnExit()
> are called last within the classlib shutdown hook.
This seems to me like saying "the VM will only know of one special
method to run instead of two". The difference is small IMHO, and
I cannot see much advantage. I can understand what you are trying to
do, but I don't think the effort is necessary.
Also, these are not the only instances of the kernel classes
having knowledge of classlib internals (Runtime class uses
org.apache.harmony.luni.internal.process.SystemProcess.create()
for example), so making this change will not resolve all the
VM-classlib contracts.
Regards,
Oliver
>
>>
>> If you feel uncomfortable with the vm directly calling
>> JarURLConnection.closeCachedFiles() and
>> DeleteOnExit.deleteOnExit(), then perhaps those calls could
>> be moved into VM.java? So, for example, you could add a private
>> method to DRLVM's VM.java which is called by the vm after running
>> all shutdown hooks, and would be responsible for calling
>> closeCachedFiles()
>> and deleteOnExit(). This way the vm is only calling methods within
>> the VM
>> class, and not directly into classlib internals.
>
> Yes, of course the dependencies could be localized within VM java.
> However, I don't think it really matters where these dependencies are
> coming from - VM.java or any other VM file, we either have them
> between VM and classlib or not :)
>
>>
>>
>> >
>> >>
>> >> >
>> >> > May be it makes sense just to move VM.closeJars() and
>> >> > VM.deleteOnExit() methods and their drlvm implementation to the
>> luni
>> >> > classlib component, under assumption that they do not really
>> contain
>> >> > any VM-specific code?
>> >>
>> >> The version of VM.java currently under luni-kernel does not contain
>> >> any VM specific code either, as all its methods simply return null :)
>> >> It does, however, give hints as to how to implement the methods
>> >> in the javadoc comments (perhaps it should clarify the reason
>> >> for not using shutdown hooks).
>> >>
>> >> As described above, I think there is a problem with this
>> implementation,
>> >> so I would not like to see it used as an example for other VM
>> >> developers.
>> >>
>> >>
>> >> I have noticed that the Javadoc comments for the DRLVM implementation
>> >> of deleteOnExit() and closeJars() both say:
>> >>
>> >> /**
>> >> * 1) This is temporary implementation
>> >> * 2) We've proposed another approach to perform shutdown actions.
>> >> */
>> >>
>> >> Have I missed the proposal of this other approach, or are the
>> comments
>> >> inaccurate?
>> >
>> > I guess there were no one on the mailing list, this seems to be a
>> > history of the past internal discussions within drlvm development
>> > team.
>> >
>> >>
>> >> > I guess it will simplify a bit the org.apache.harmony.kernel.vm.VM
>> >> > interface as well as would allow to avoid extra dependencies
>> between
>> >> > VM and classlib.
>> >> >
>> >>
>> >> IMHO there is no problem for kernel classes to have dependencies on
>> >> classlib - they are, after all, just another part of the class
>> >> library that
>> >> happens to get developed separately due to their nature.
>> >
>> > Actually I thought of the kernel classes being part of VM since they
>> > are tied to VM-specific functionality. If this is true, then it may be
>> > good if we can keep the interface between VM and classlib "clean",
>> > e.g. without dependencies on the API which doesn't appear in J2SE.
>>
>> Although we want to keep the classlib VM-independent, I don't think
>> there
>> is a need to keep the vm kernel totally classlib-independent (since the
>> Harmony project currently aims to only have one classlib but multiple
>> VMs).
>> In other words, I don't see a problem with any kernel implementation
>> having
>> knowledge of classlib internals, especially when they are contained
>> within the
>> same module (ie luni-kernel has deps on luni).
>
> One possible inconvenience could be, if the shutdown hooks are changed
> somehow in classlib (e.g. more hooks are added, or existing ones are
> changed/removed), shutdown hooks interface will be changed and VM will
> have to be updated synchronously. Isn't this a modularity issue?
> However, I completely agree this works OK as long as we have one
> classlib and as long as it's internal implementation (e.g resource
> cleanup) isn't changed.
> I think this is just a matter of archiving the good modularity level,
> it is true the code can always work without it.
>
> Thanks,
> Andrey.
>
>>
>> Regards,
>> Oliver
>>
>> >
>> > Thanks,
>> > Andrey.
>> >
>> >>
>> >> Regards,
>> >> Oliver
>> >>
>> >> --
>> >> Oliver Deakin
>> >> IBM United Kingdom Limited
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> Oliver Deakin
>> IBM United Kingdom Limited
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Is it OK for VM kernel class to call internal classlib API?
Posted by Andrey Chernyshev <a....@gmail.com>.
On 7/10/06, Oliver Deakin <ol...@googlemail.com> wrote:
> Andrey Chernyshev wrote:
> > On 7/7/06, Oliver Deakin <ol...@googlemail.com> wrote:
> >> Andrey Chernyshev wrote:
> >> > I was trying to compile the kernel classes set from DRLVM
> >> independently
> >> > from the classlib and found it difficult because kernel classes set
> >> > currently have a dependence on the internal classlib API, e.g.
> >> > org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection
> >> > and org.apache.harmony.luni.util.DeleteOnExit classes.
> >> >
> >> > I've found the spec for kernel class org.apache.harmony.kernel.vm.VM
> >> > (l'm looking at
> >> >
> >> classlib\trunk\modules\luni-kernel\src\main\java\org\apache\harmony\kernel\vm\VM.java)
> >>
> >> >
> >> > assumes that VM is calling excplicitly
> >> > JarURLConnection.closeCachedFiles()
> >> > and DeleteOnExit.deleteOnExit() during VM shutdown.
> >> >
> >> > On the other hand, there is standard API in J2SE called
> >> > java.lang.Runtime.addShutdownHook(Thread) which can be used to specify
> >> > the
> >> > tasks that have to be done during VM shutdown.
> >> > BTW, this is exactly how DRLVM implements these methods in it's
> >> > VM.java. For example, for VM.closeJars() it currently does like:
> >> >
> >> > public static void closeJars() {
> >> > class CloseJarsHook implements Runnable {
> >> > public void run() {
> >> > JarURLConnection.closeCachedFiles();
> >> > }
> >> > }
> >> > ...
> >> > Runtime.getRuntime().addShutdownHook(new Thread(new
> >> > CloseJarsHook()));
> >> > }
> >> >
> >> > Are there any problems with this approach, should the DRLVM (or other
> >> > Vm's) implement these methods differently?
> >>
> >> There is a potential problem with this approach. The code that is run
> >> by the
> >> shutdown hooks is not restricted in its behaviour and the order that the
> >> shutdown hooks are executed in is not guaranteed. If the deleteOnExit()
> >> and/or closeCachedFiles are not the last hooks to be executed, it is
> >> quite
> >> possible that a subsequent shutdown hook could try to access files that
> >> have already been deleted. The only way to guarantee that this will
> >> never happen is to make sure that deleteOnExit() and closeCachedFiles()
> >> are called after all shutdown hooks have completed.
> >>
> >> Of course, how this is implemented is down to the VM developer - but
> >> I would strongly recommend not using shutdown hooks for this purpose.
> >
> > Thanks Oliver, this explanation sounds reasonable.
> > If the issue is just in the shutdown hooks order, then, still may be
> > it makes sense to add VM.addClasslibShutdownHook(Runnable) method or
> > something like that, which can be:
> > - used by the classlib to do whatever resource cleanup / shutdown
> > works they need;
> > - guaranteed by VM to be executed always after Runtime's shutdown
> > hooks are done (can be specified in the contract)?
> > This approach looks more universal than having two specific methods
> > cloaseJars() and deletOnExit(). It will also allow VM to do not call
> > internal classlib API explicitly.
>
> I think the same problem exists with this approach. You still need to
> guarantee that closeCachedFiles() and deleteOnExit() are the last classlib
> shutdown hooks that are called, otherwise they may cause problems
I think class lib could add just one shutdown hook which is guaranteed
by VM to be run after all other (e.g. application's) shutdown hooks
are completed.
Within this shutdown hook, classlib are free to choose whatever order
they like, e.g. run all others hooks (whatever may appear in classlib
in the future) and then finally call closeCachedFiles() and
deleteOnExit().
My point was that, if classlib do really care about the shutdown
sequence of it's internal resources, it should be classlib who defines
the shutdown hooks execution order, not VM. IMHO there is no need to
bring this up to the classlib<->VM contract.
> with any classlib shutdown hooks called after them. Once you put
> a restriction on the classlib shutdown hooks that closeCachedFiles() and
> deleteOnExit() will be that last ones called, you are basically
> in a similar situation to just calling the methods explicitly after all
> shutdown hooks complete.
I agree the situation is exactly the same in terms of the code being
executed, the only question is where this code is located - VM.java
(which is a part of VM, right?) or classlib. I think the good
interface between VM and classlib would minimize VM's knowledge about
classlib and vice versa. In the ideal situation, I would limit it to a
subset of J2SE API.
>
> I think it would be fine to add an addClasslibShutdownHook() method
> to VM if it was needed, but at the moment I don't believe it is. You are
well, to be precise, I'm suggesting to replace existing VM.closeJars()
and VM.deletOnExit() with VM.addClasslibShutdownHook(), not just to
add :)
> always going to be in the position of requiring closeCachedFiles()
> and deleteOnExit() to run last, and adding an extra shutdown hook
> mechanism will not change that.
I thought of:
- VM could guarantee that the classlib shutdown hook is run last;
- Classlib could guarantee that closeCachedFiles() and deleteOnExit()
are called last within the classlib shutdown hook.
>
> If you feel uncomfortable with the vm directly calling
> JarURLConnection.closeCachedFiles() and
> DeleteOnExit.deleteOnExit(), then perhaps those calls could
> be moved into VM.java? So, for example, you could add a private
> method to DRLVM's VM.java which is called by the vm after running
> all shutdown hooks, and would be responsible for calling closeCachedFiles()
> and deleteOnExit(). This way the vm is only calling methods within the VM
> class, and not directly into classlib internals.
Yes, of course the dependencies could be localized within VM java.
However, I don't think it really matters where these dependencies are
coming from - VM.java or any other VM file, we either have them
between VM and classlib or not :)
>
>
> >
> >>
> >> >
> >> > May be it makes sense just to move VM.closeJars() and
> >> > VM.deleteOnExit() methods and their drlvm implementation to the luni
> >> > classlib component, under assumption that they do not really contain
> >> > any VM-specific code?
> >>
> >> The version of VM.java currently under luni-kernel does not contain
> >> any VM specific code either, as all its methods simply return null :)
> >> It does, however, give hints as to how to implement the methods
> >> in the javadoc comments (perhaps it should clarify the reason
> >> for not using shutdown hooks).
> >>
> >> As described above, I think there is a problem with this implementation,
> >> so I would not like to see it used as an example for other VM
> >> developers.
> >>
> >>
> >> I have noticed that the Javadoc comments for the DRLVM implementation
> >> of deleteOnExit() and closeJars() both say:
> >>
> >> /**
> >> * 1) This is temporary implementation
> >> * 2) We've proposed another approach to perform shutdown actions.
> >> */
> >>
> >> Have I missed the proposal of this other approach, or are the comments
> >> inaccurate?
> >
> > I guess there were no one on the mailing list, this seems to be a
> > history of the past internal discussions within drlvm development
> > team.
> >
> >>
> >> > I guess it will simplify a bit the org.apache.harmony.kernel.vm.VM
> >> > interface as well as would allow to avoid extra dependencies between
> >> > VM and classlib.
> >> >
> >>
> >> IMHO there is no problem for kernel classes to have dependencies on
> >> classlib - they are, after all, just another part of the class
> >> library that
> >> happens to get developed separately due to their nature.
> >
> > Actually I thought of the kernel classes being part of VM since they
> > are tied to VM-specific functionality. If this is true, then it may be
> > good if we can keep the interface between VM and classlib "clean",
> > e.g. without dependencies on the API which doesn't appear in J2SE.
>
> Although we want to keep the classlib VM-independent, I don't think there
> is a need to keep the vm kernel totally classlib-independent (since the
> Harmony project currently aims to only have one classlib but multiple VMs).
> In other words, I don't see a problem with any kernel implementation having
> knowledge of classlib internals, especially when they are contained
> within the
> same module (ie luni-kernel has deps on luni).
One possible inconvenience could be, if the shutdown hooks are changed
somehow in classlib (e.g. more hooks are added, or existing ones are
changed/removed), shutdown hooks interface will be changed and VM will
have to be updated synchronously. Isn't this a modularity issue?
However, I completely agree this works OK as long as we have one
classlib and as long as it's internal implementation (e.g resource
cleanup) isn't changed.
I think this is just a matter of archiving the good modularity level,
it is true the code can always work without it.
Thanks,
Andrey.
>
> Regards,
> Oliver
>
> >
> > Thanks,
> > Andrey.
> >
> >>
> >> Regards,
> >> Oliver
> >>
> >> --
> >> Oliver Deakin
> >> IBM United Kingdom Limited
> >>
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Is it OK for VM kernel class to call internal classlib
API?
Posted by Oliver Deakin <ol...@googlemail.com>.
Andrey Chernyshev wrote:
> On 7/7/06, Oliver Deakin <ol...@googlemail.com> wrote:
>> Andrey Chernyshev wrote:
>> > I was trying to compile the kernel classes set from DRLVM
>> independently
>> > from the classlib and found it difficult because kernel classes set
>> > currently have a dependence on the internal classlib API, e.g.
>> > org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection
>> > and org.apache.harmony.luni.util.DeleteOnExit classes.
>> >
>> > I've found the spec for kernel class org.apache.harmony.kernel.vm.VM
>> > (l'm looking at
>> >
>> classlib\trunk\modules\luni-kernel\src\main\java\org\apache\harmony\kernel\vm\VM.java)
>>
>> >
>> > assumes that VM is calling excplicitly
>> > JarURLConnection.closeCachedFiles()
>> > and DeleteOnExit.deleteOnExit() during VM shutdown.
>> >
>> > On the other hand, there is standard API in J2SE called
>> > java.lang.Runtime.addShutdownHook(Thread) which can be used to specify
>> > the
>> > tasks that have to be done during VM shutdown.
>> > BTW, this is exactly how DRLVM implements these methods in it's
>> > VM.java. For example, for VM.closeJars() it currently does like:
>> >
>> > public static void closeJars() {
>> > class CloseJarsHook implements Runnable {
>> > public void run() {
>> > JarURLConnection.closeCachedFiles();
>> > }
>> > }
>> > ...
>> > Runtime.getRuntime().addShutdownHook(new Thread(new
>> > CloseJarsHook()));
>> > }
>> >
>> > Are there any problems with this approach, should the DRLVM (or other
>> > Vm's) implement these methods differently?
>>
>> There is a potential problem with this approach. The code that is run
>> by the
>> shutdown hooks is not restricted in its behaviour and the order that the
>> shutdown hooks are executed in is not guaranteed. If the deleteOnExit()
>> and/or closeCachedFiles are not the last hooks to be executed, it is
>> quite
>> possible that a subsequent shutdown hook could try to access files that
>> have already been deleted. The only way to guarantee that this will
>> never happen is to make sure that deleteOnExit() and closeCachedFiles()
>> are called after all shutdown hooks have completed.
>>
>> Of course, how this is implemented is down to the VM developer - but
>> I would strongly recommend not using shutdown hooks for this purpose.
>
> Thanks Oliver, this explanation sounds reasonable.
> If the issue is just in the shutdown hooks order, then, still may be
> it makes sense to add VM.addClasslibShutdownHook(Runnable) method or
> something like that, which can be:
> - used by the classlib to do whatever resource cleanup / shutdown
> works they need;
> - guaranteed by VM to be executed always after Runtime's shutdown
> hooks are done (can be specified in the contract)?
> This approach looks more universal than having two specific methods
> cloaseJars() and deletOnExit(). It will also allow VM to do not call
> internal classlib API explicitly.
I think the same problem exists with this approach. You still need to
guarantee that closeCachedFiles() and deleteOnExit() are the last classlib
shutdown hooks that are called, otherwise they may cause problems
with any classlib shutdown hooks called after them. Once you put
a restriction on the classlib shutdown hooks that closeCachedFiles() and
deleteOnExit() will be that last ones called, you are basically
in a similar situation to just calling the methods explicitly after all
shutdown hooks complete.
I think it would be fine to add an addClasslibShutdownHook() method
to VM if it was needed, but at the moment I don't believe it is. You are
always going to be in the position of requiring closeCachedFiles()
and deleteOnExit() to run last, and adding an extra shutdown hook
mechanism will not change that.
If you feel uncomfortable with the vm directly calling
JarURLConnection.closeCachedFiles() and
DeleteOnExit.deleteOnExit(), then perhaps those calls could
be moved into VM.java? So, for example, you could add a private
method to DRLVM's VM.java which is called by the vm after running
all shutdown hooks, and would be responsible for calling closeCachedFiles()
and deleteOnExit(). This way the vm is only calling methods within the VM
class, and not directly into classlib internals.
>
>>
>> >
>> > May be it makes sense just to move VM.closeJars() and
>> > VM.deleteOnExit() methods and their drlvm implementation to the luni
>> > classlib component, under assumption that they do not really contain
>> > any VM-specific code?
>>
>> The version of VM.java currently under luni-kernel does not contain
>> any VM specific code either, as all its methods simply return null :)
>> It does, however, give hints as to how to implement the methods
>> in the javadoc comments (perhaps it should clarify the reason
>> for not using shutdown hooks).
>>
>> As described above, I think there is a problem with this implementation,
>> so I would not like to see it used as an example for other VM
>> developers.
>>
>>
>> I have noticed that the Javadoc comments for the DRLVM implementation
>> of deleteOnExit() and closeJars() both say:
>>
>> /**
>> * 1) This is temporary implementation
>> * 2) We've proposed another approach to perform shutdown actions.
>> */
>>
>> Have I missed the proposal of this other approach, or are the comments
>> inaccurate?
>
> I guess there were no one on the mailing list, this seems to be a
> history of the past internal discussions within drlvm development
> team.
>
>>
>> > I guess it will simplify a bit the org.apache.harmony.kernel.vm.VM
>> > interface as well as would allow to avoid extra dependencies between
>> > VM and classlib.
>> >
>>
>> IMHO there is no problem for kernel classes to have dependencies on
>> classlib - they are, after all, just another part of the class
>> library that
>> happens to get developed separately due to their nature.
>
> Actually I thought of the kernel classes being part of VM since they
> are tied to VM-specific functionality. If this is true, then it may be
> good if we can keep the interface between VM and classlib "clean",
> e.g. without dependencies on the API which doesn't appear in J2SE.
Although we want to keep the classlib VM-independent, I don't think there
is a need to keep the vm kernel totally classlib-independent (since the
Harmony project currently aims to only have one classlib but multiple VMs).
In other words, I don't see a problem with any kernel implementation having
knowledge of classlib internals, especially when they are contained
within the
same module (ie luni-kernel has deps on luni).
Regards,
Oliver
>
> Thanks,
> Andrey.
>
>>
>> Regards,
>> Oliver
>>
>> --
>> Oliver Deakin
>> IBM United Kingdom Limited
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Is it OK for VM kernel class to call internal classlib API?
Posted by Andrey Chernyshev <a....@gmail.com>.
On 7/7/06, Oliver Deakin <ol...@googlemail.com> wrote:
> Andrey Chernyshev wrote:
> > I was trying to compile the kernel classes set from DRLVM independently
> > from the classlib and found it difficult because kernel classes set
> > currently have a dependence on the internal classlib API, e.g.
> > org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection
> > and org.apache.harmony.luni.util.DeleteOnExit classes.
> >
> > I've found the spec for kernel class org.apache.harmony.kernel.vm.VM
> > (l'm looking at
> > classlib\trunk\modules\luni-kernel\src\main\java\org\apache\harmony\kernel\vm\VM.java)
> >
> > assumes that VM is calling excplicitly
> > JarURLConnection.closeCachedFiles()
> > and DeleteOnExit.deleteOnExit() during VM shutdown.
> >
> > On the other hand, there is standard API in J2SE called
> > java.lang.Runtime.addShutdownHook(Thread) which can be used to specify
> > the
> > tasks that have to be done during VM shutdown.
> > BTW, this is exactly how DRLVM implements these methods in it's
> > VM.java. For example, for VM.closeJars() it currently does like:
> >
> > public static void closeJars() {
> > class CloseJarsHook implements Runnable {
> > public void run() {
> > JarURLConnection.closeCachedFiles();
> > }
> > }
> > ...
> > Runtime.getRuntime().addShutdownHook(new Thread(new
> > CloseJarsHook()));
> > }
> >
> > Are there any problems with this approach, should the DRLVM (or other
> > Vm's) implement these methods differently?
>
> There is a potential problem with this approach. The code that is run by the
> shutdown hooks is not restricted in its behaviour and the order that the
> shutdown hooks are executed in is not guaranteed. If the deleteOnExit()
> and/or closeCachedFiles are not the last hooks to be executed, it is quite
> possible that a subsequent shutdown hook could try to access files that
> have already been deleted. The only way to guarantee that this will
> never happen is to make sure that deleteOnExit() and closeCachedFiles()
> are called after all shutdown hooks have completed.
>
> Of course, how this is implemented is down to the VM developer - but
> I would strongly recommend not using shutdown hooks for this purpose.
Thanks Oliver, this explanation sounds reasonable.
If the issue is just in the shutdown hooks order, then, still may be
it makes sense to add VM.addClasslibShutdownHook(Runnable) method or
something like that, which can be:
- used by the classlib to do whatever resource cleanup / shutdown
works they need;
- guaranteed by VM to be executed always after Runtime's shutdown
hooks are done (can be specified in the contract)?
This approach looks more universal than having two specific methods
cloaseJars() and deletOnExit(). It will also allow VM to do not call
internal classlib API explicitly.
>
> >
> > May be it makes sense just to move VM.closeJars() and
> > VM.deleteOnExit() methods and their drlvm implementation to the luni
> > classlib component, under assumption that they do not really contain
> > any VM-specific code?
>
> The version of VM.java currently under luni-kernel does not contain
> any VM specific code either, as all its methods simply return null :)
> It does, however, give hints as to how to implement the methods
> in the javadoc comments (perhaps it should clarify the reason
> for not using shutdown hooks).
>
> As described above, I think there is a problem with this implementation,
> so I would not like to see it used as an example for other VM
> developers.
>
>
> I have noticed that the Javadoc comments for the DRLVM implementation
> of deleteOnExit() and closeJars() both say:
>
> /**
> * 1) This is temporary implementation
> * 2) We've proposed another approach to perform shutdown actions.
> */
>
> Have I missed the proposal of this other approach, or are the comments
> inaccurate?
I guess there were no one on the mailing list, this seems to be a
history of the past internal discussions within drlvm development
team.
>
> > I guess it will simplify a bit the org.apache.harmony.kernel.vm.VM
> > interface as well as would allow to avoid extra dependencies between
> > VM and classlib.
> >
>
> IMHO there is no problem for kernel classes to have dependencies on
> classlib - they are, after all, just another part of the class library that
> happens to get developed separately due to their nature.
Actually I thought of the kernel classes being part of VM since they
are tied to VM-specific functionality. If this is true, then it may be
good if we can keep the interface between VM and classlib "clean",
e.g. without dependencies on the API which doesn't appear in J2SE.
Thanks,
Andrey.
>
> Regards,
> Oliver
>
> --
> Oliver Deakin
> IBM United Kingdom Limited
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] Is it OK for VM kernel class to call internal classlib
API?
Posted by Oliver Deakin <ol...@googlemail.com>.
Andrey Chernyshev wrote:
> I was trying to compile the kernel classes set from DRLVM independently
> from the classlib and found it difficult because kernel classes set
> currently have a dependence on the internal classlib API, e.g.
> org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection
> and org.apache.harmony.luni.util.DeleteOnExit classes.
>
> I've found the spec for kernel class org.apache.harmony.kernel.vm.VM
> (l'm looking at
> classlib\trunk\modules\luni-kernel\src\main\java\org\apache\harmony\kernel\vm\VM.java)
>
> assumes that VM is calling excplicitly
> JarURLConnection.closeCachedFiles()
> and DeleteOnExit.deleteOnExit() during VM shutdown.
>
> On the other hand, there is standard API in J2SE called
> java.lang.Runtime.addShutdownHook(Thread) which can be used to specify
> the
> tasks that have to be done during VM shutdown.
> BTW, this is exactly how DRLVM implements these methods in it's
> VM.java. For example, for VM.closeJars() it currently does like:
>
> public static void closeJars() {
> class CloseJarsHook implements Runnable {
> public void run() {
> JarURLConnection.closeCachedFiles();
> }
> }
> ...
> Runtime.getRuntime().addShutdownHook(new Thread(new
> CloseJarsHook()));
> }
>
> Are there any problems with this approach, should the DRLVM (or other
> Vm's) implement these methods differently?
There is a potential problem with this approach. The code that is run by the
shutdown hooks is not restricted in its behaviour and the order that the
shutdown hooks are executed in is not guaranteed. If the deleteOnExit()
and/or closeCachedFiles are not the last hooks to be executed, it is quite
possible that a subsequent shutdown hook could try to access files that
have already been deleted. The only way to guarantee that this will
never happen is to make sure that deleteOnExit() and closeCachedFiles()
are called after all shutdown hooks have completed.
Of course, how this is implemented is down to the VM developer - but
I would strongly recommend not using shutdown hooks for this purpose.
>
> May be it makes sense just to move VM.closeJars() and
> VM.deleteOnExit() methods and their drlvm implementation to the luni
> classlib component, under assumption that they do not really contain
> any VM-specific code?
The version of VM.java currently under luni-kernel does not contain
any VM specific code either, as all its methods simply return null :)
It does, however, give hints as to how to implement the methods
in the javadoc comments (perhaps it should clarify the reason
for not using shutdown hooks).
As described above, I think there is a problem with this implementation,
so I would not like to see it used as an example for other VM
developers.
I have noticed that the Javadoc comments for the DRLVM implementation
of deleteOnExit() and closeJars() both say:
/**
* 1) This is temporary implementation
* 2) We've proposed another approach to perform shutdown actions.
*/
Have I missed the proposal of this other approach, or are the comments
inaccurate?
> I guess it will simplify a bit the org.apache.harmony.kernel.vm.VM
> interface as well as would allow to avoid extra dependencies between
> VM and classlib.
>
IMHO there is no problem for kernel classes to have dependencies on
classlib - they are, after all, just another part of the class library that
happens to get developed separately due to their nature.
Regards,
Oliver
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org